Flagship Report

2026 Global Supply Chain Threat Intelligence Report

One supplier fails, and thousands of healthy networks become a single shared incident. This is what 2025 taught, read case by case: how the compromises happened, what they had in common, and where the next one is already forming. A flagship assessment for the people who have to decide before the picture is complete.

28 pages

A single compromised supplier can turn thousands of healthy networks into one shared incident.

Executive summary

In 2025, the most damaging cyber events rarely looked like traditional breaches. They looked like trust being quietly rerouted. Instead of forcing their way into a single network, adversaries gained position in shared dependencies, third-party platforms, supplier environments, and outsourced identity processes, then used those pathways to reach many organizations at once.

These incidents did not begin with a dramatic “break-in” to a company’s network. They began in quieter places where modern business runs on autopilot: a software dependency pulled into a build overnight, a file transfer service that moves sensitive records between partners, a supplier’s engineering environment that holds the blueprint of a widely deployed product, or a help desk workflow that can reset identity in minutes. Adversaries did not need to defeat every control inside a target. They needed to gain position in one shared dependency, then let the downstream connections do the work.

What made these events expensive was not merely technical ingenuity. It was cascade. A single compromise became many simultaneous incidents because shared components, shared platforms, and shared service providers create shared exposure. When the trust layer is poisoned, the cost multiplies quickly: operations slow or stop, investigation must scale across teams and environments, legal and regulatory obligations trigger on tight timelines, and customers and partners demand evidence of what was affected and what was not. In that moment, organizations are not only responding to an intrusion. They are restoring confidence in the integrity of their software, their vendors, and their own ability to manage systemic risk.

This report focuses on four core cases, plus one short spotlight. The sequence is intentional. It builds from ecosystem scale (npm) to enterprise data exchange concentration (Cleo), to strategic supplier compromise (F5), to human trust and outsourced processes (Scattered Spider), and finally to public sector continuity (Miljödata Sweden). Each case is written for decision makers: what happened, how it spread, why it mattered, and what measurably reduces risk.

What changed in 2025

In 2025, supply chain compromise became less of a rare, specialist scenario and more of a repeatable operating model for attackers. The shift was not only about which technologies were targeted, but about how risk moved. Adversaries increasingly focused on the mechanisms that modern organizations used to scale work quickly and safely: developer identity, access tokens, and automated build and deployment pipelines. When those trust signals are stolen or redirected, compromise can travel at the speed of routine software delivery, often outpacing human review and conventional change control.

At the same time, 2025 made clear that the highest-leverage targets are not always the most complex systems, but the most connected ones. Business infrastructure platforms that sit on organizational boundaries, especially managed file transfer services, continue to attract attention because they exist to link partners and move sensitive, regulated data reliably. When a vulnerability is exploited or a supplier environment is compromised, the impact rarely stays contained inside one organization.

The platform itself becomes the multiplier, turning a single point of weakness into a multi-victim event with operational disruption, legal exposure, and a prolonged need to prove what was accessed and what was not.

Finally, the year has reinforced that supply chain risk is as much operational and strategic as it is technical. Supplier development environments have become attractive because they hold the blueprint for widely deployed technology and can create long-tail exposure. Identity recovery processes have become attractive because they can be manipulated to bypass strong perimeter and endpoint controls through legitimate business workflows. In parallel, concentrated public- sector suppliers have demonstrated how a single incident can disrupt civic continuity at scale. For leaders, the practical lesson is not simply to harden endpoints, but to govern trust paths, the systems, relationships, and processes that determine how code, data, and identity move across the enterprise and its ecosystem.

Cases

npm and Shai-Hulud (September 2025): attackers hijacked trusted npm package maintainer accounts and, through the Shai-Hulud worm, used poisoned updates to steal developer tokens and spread malicious code across the JavaScript software supply chain.

Cleo managed file transfer (late 2024 to 2025 disclosures): vulnerabilities in Cleo Harmony, VLTrader, and LexiCom were exploited to enable remote code execution, with downstream impacts disclosed by large organizations including Hertz.

F5 supplier compromise (disclosed October 2025): a highly sophisticated, nation-state affiliated threat actor maintained persistent access to certain F5 systems and downloaded files including portions of BIG-IP source code and vulnerability information, raising long tail risk.

Scattered Spider spotlight (updated July 2025): financially motivated operators exploited trusted relationships and help desk workflows to reset credentials and modify multi-factor authentication, often abusing contracted IT support.

Miljödata Sweden (August 2025): a ransomware incident at an IT supplier used by many Swedish municipalities disrupted HR and sick leave related systems across a large portion of local government.

Top cross-case findings

Across these incidents, the common pattern was not technical novelty. It was leverage. Adversaries repeatedly targeted upstream trust points where a small intrusion could create many downstream victims, whether through software publishing authority, boundary platforms that move sensitive data, supplier environments that enable future exploitation, or identity recovery processes that can grant privileged access quickly. The practical consequence for leaders is that supply chain risk scales through relationships and dependencies, and the fastest way to reduce exposure is to govern the trust paths that connect systems, vendors, and people, not only to harden endpoints.

Recommended actions

Analysts note that the organizations that contained these events fastest tended to do three things well: they could map exposure quickly, they reduced credential leverage decisively, and they validated closure with evidence rather than assumption. In operational terms, that means maintaining a current dependency and vendor footprint, rotating and scoping credentials after credible exposure signals, and confirming remediation through rebuild and verification steps that can stand up to scrutiny from customers, auditors, and regulators. These are measurable capabilities, and they are the difference between a bounded incident and a cascading trust failure.

Case 1: npm ecosystem compromise and the Shai-Hulud worm

In modern software development, dependency downloads and automated builds are not optional conveniences. They are the factory line. The npm (Node Package Manager, a central distribution hub where software teams pull widely used third-party JavaScript components that become part of their products and internal systems) registry is a critical component of that factory line for JavaScript and Node.js ecosystems.

In September 2025, attackers abused trust in the npm ecosystem by taking over legitimate maintainer credentials and publishing malicious updates to widely used JavaScript packages, including Chalk and Debug. [1] In parallel, a malware campaign widely referred to as Shai-Hulud harvested developer secrets such as access tokens and then used those credentials to push additional poisoned packages, often by abusing installation scripts that run automatically when software is built or deployed. [1][3]

The risk for organizations is not theoretical, because this is the software equivalent of contaminating an ingredient supplier. You can be compromised without being directly targeted. Modern engineering teams pull npm packages into products and internal tools at machine speed, so a short window of malicious updates can still ripple into builds, developer laptops, and even production systems. The most serious downstream risk is not only the malicious code itself, but the credentials it can steal. These credentials can unlock source code, cloud environments, and build pipelines, turning a “dependency issue” into an enterprise intrusion with a large blast radius and expensive assurance work to prove what was affected and what was not. [1][2][3]

Sequence of events

September 8, 2025: attackers obtained credentials for a trusted npm maintainer and pushed malicious updates to 18 popular packages, including Chalk and Debug. [1] September 15, 2025: Shai-Hulud activity was reported as a worm-like propagation phase that harvested credentials and republished infected packages through the npm trust chain. [1][3] Early waves were described as expanding rapidly, with later waves and broader npm campaign learnings documented by AWS in late 2025, and Unit 42 describing compromise affecting hundreds of packages. [2][3]

Anatomy of compromise (from initial access to cascade)

Initial access. Available reporting indicates the first phase relied on compromised credentials for a trusted package maintainer. This is a recurring supply chain entry point because maintainer accounts function as distribution authorities. When a maintainer token is compromised, a threat actor can publish code that inherits the credibility of the dependency itself. [1][3]

Execution and persistence. In the early wave, malicious updates were designed to run as part of standard installation or runtime behavior. Public reporting describes payload intent that included cryptocurrency-related theft or manipulation. The brief availability window still mattered because automated build systems and downstream applications pulled packages at machine speed. Even a short exposure window can create broad downstream impact. [1][3]

Propagation. The Shai-Hulud phase represented a step change. Reporting describes the worm using footholds in developer environments to harvest credentials, including npm tokens, GitHub personal access tokens, and cloud credentials. Where npm tokens were available, the malware republished packages to include the worm payload, often executed via post-install scripts, extending reach across additional projects that installed the affected packages. [1][3]

Downstream impact. The primary damage mechanism was not only compromise of a dependency. It was secondary compromise enabled by stolen secrets. Once developer tokens and cloud credentials are harvested, the incident can shift from software integrity into enterprise compromise and persistence through build and deployment systems. Unit 42 described compromise affecting hundreds of packages and noted indicators consistent with automated propagation. [3]

Impact and implications (business, technical, geopolitical)

Business. Exposure is difficult to bound. Organizations must answer what was built, when, and with which dependency versions, often across many teams and repositories. [2] Technical: This incident exploited normal behavior. Package managers, build systems, and developer automation performed exactly as designed, which complicated detection and increased the need for strong dependency governance and build integrity controls. [1][2][3] Geopolitical: Ecosystem-level compromise creates strategic advantage because it enables wide access options without direct targeting and can be conducted by criminal groups or state-aligned actors with plausible deniability, depending on follow-on intent and targeting. [3] Market trust: Software buyers increasingly treat software integrity as part of supplier due diligence, not only a development concern, which raises expectations for evidence-based assurance after incidents. [2]

Analyst assessment

Analysts assess with moderate confidence that the most material risk in the Shai-Hulud phase came from credential harvesting and token reuse, not from any single payload feature. This assessment is based on consistent descriptions across AWS and Unit 42 reporting that emphasize theft of npm tokens, GitHub tokens, and cloud credentials, combined with a republish-driven propagation model. [1][2][3]

Controls that measurably reduce risk

Organizations typically reduce exposure by enforcing dependency discipline, including pinning versions for production builds and requiring review gates for dependency upgrades in high-risk paths. [2] Token minimization is also critical: scoped, short-lived tokens for registries and code hosting reduce the value of stolen secrets, and long-lived tokens should be removed from developer workstations where possible. [2] Build isolation further limits cascade risk by separating build identities from user identities and preventing build pipelines from reusing developer tokens. [2]

Continuous detection should include monitoring for new or unexpected post-install scripts and unauthorized workflow changes in code repositories. [3] Finally, evidence of closure matters: after an incident, organizations benefit from proving packages were rebuilt from known clean sources and that secrets were rotated and invalidated, rather than assuming remediation is complete. [2]

Case 2: Cleo managed file transfer exploitation and downstream impacts

Cleo is a software vendor that sells tools many companies use to move important business files back and forth with partners, customers, and internal systems, such as payroll files, invoices, shipment data, customer records, and other sensitive documents that must be exchanged reliably and on schedule.

Cleo’s products, including Harmony, VLTrader, and LexiCom, act as the “secure courier” and automation layer for those transfers, so files move automatically with logging and controls rather than being sent manually through email. [4][5] These systems often sit at a high-leverage choke point in the business. If attackers break into the file transfer platform, they can potentially see, steal, or tamper with the data that passes through it, and in some cases use it as a doorway into connected systems. Even if a company’s core network stays intact, the incident can still be severe because the compromised system is the one that handles regulated or high-value data exchange and touches many partners and workflows. [6]

In late 2024, Cleo published advisories for critical vulnerabilities affecting Cleo Harmony, VLTrader, and LexiCom. [4][5] In 2025, downstream organizations disclosed impacts tied to exploitation of these flaws, illustrating how compromise at a vendor layer can produce a multi-victim event even when each victim maintains strong internal network security controls. [6][7]

Sequence of events

On December 10, 2024, Cleo published a security advisory for CVE-2024-50623. [4] On December 14, 2024, Cleo published a security update for CVE-2024-55956 and advised customers to upgrade to a patched version, describing conditions under which unauthenticated command execution could be possible. [5] In January 2025, Huntress reported active exploitation concerns and published analysis focused on patch effectiveness and exploitation behavior observed in the wild. [7] In April 2025, Reuters reported that Hertz disclosed attackers had exploited vulnerabilities in Cleo’s file transfer platform during prior months, resulting in theft of customer data and a public breach notice. [6]

Anatomy of compromise (why managed file transfer incidents cascade)

Entry point. Critical vulnerabilities in externally reachable file transfer services can create direct access paths. Cleo’s advisories describe behaviors that could enable remote code execution in certain affected versions. [4][5] Remote code execution means an attacker can run commands on the server hosting the file transfer service, which can enable data access, persistence, and potential movement into connected environments.

Operational reality. Managed file transfer systems are commonly integrated into business workflows and partner connections. They often maintain partner configurations, job schedules, and automation logic, and in many environments they also store credentials or keys that enable automated transfers. Huntress reporting highlights why exploitation of such platforms can be operationally consequential even when the affected organization’s broader network defenses are strong. [7]

Downstream impact. Reuters reported that Hertz stated its own network was not affected, but customer data was stolen through a vendor event involving Cleo Communications. [6] This is a recurring pattern in third-party compromise: the impacted organization can still face notification, regulatory reporting, and customer remediation costs even when the intrusion does not originate inside its enterprise network. [6]

Impact and implications (business, technical, geopolitical)

From a business perspective, managed file transfer incidents tend to touch regulated and identity-linked data, which can create legal exposure and customer trust costs that scale quickly. [6] Technically, these platforms often sit at the boundary between organizations and are designed to connect partners and workflows, which increases blast radius when a platform is vulnerable or compromised. [4][5][7] Strategically, cross-border data movement is a dependency for many enterprises; when shared transfer rails are compromised, it can affect international partners and compliance obligations and can create additional exposure for multinationals that must report across jurisdictions. [6] The broader risk governance lesson is that supplier risk must explicitly include externally reachable services, patch velocity, and evidence of secure configuration, not only questionnaire- based attestation. [4][5][7]

Analyst assessment

Analysts assess with high confidence that vendor-layer compromise in managed file transfer environments produces outsized downstream cost because it sits on the legal and reputational boundary. Even a contained event at the vendor layer can trigger notification, remediation, and customer assurance work across many affected organizations. This assessment is based on Cleo advisories describing critical exploitation pathways, Huntress reporting on active exploitation concerns, and downstream disclosure such as Hertz. [4][5][6][7]

Controls that measurably reduce risk

Organizations reduce exposure most effectively when they treat managed file transfer as a governed boundary platform rather than a utility service. That begins with asset exposure inventory: knowing awareness-level basics, such as which file transfer services are internet- facing, which business processes depend on them, and who owns patching and configuration decisions. [4][5] It also requires patch velocity with evidence, meaning verifiable patch status and configuration- hardening artifacts for high-risk managed file transfer assets, not informal confirmation. [4][5][7]

Data minimization reduces impact when compromise occurs: limiting sensitive staging directories, encrypting data at rest and in transit, and managing keys tightly so that platform compromise does not automatically equal data compromise. Credential containment matters as well. Avoid storing broad, long-lived credentials on managed file transfer servers; prefer scoped and short-lived credentials where possible and rotate immediately after credible vendor advisories or exposure signals. [5][7] Finally, downstream assurance should be contractual and operational: require supplier incident closure documentation that includes timeline, exploited vectors, and compensating controls, because assurance is often the cost driver after the technical containment phase. [6][7]

Case 3: F5 supplier compromise and the strategic enablement problem

F5 is a major infrastructure vendor whose technology is commonly deployed in front of an organization’s most important applications to manage and secure traffic. Its flagship product line, BIG-IP, is often part of the “front door” of digital business, which is why a supplier compromise at F5 matters beyond F5 itself.

Some supply chain incidents are not about vulnerability in a customer environment. They are about the compromise of the supplier itself. In October 2025, government and vendor-facing communications described a security incident at F5 involving persistent access by a highly sophisticated nation-state or nation-state-affiliated threat actor, and the downloading of files from certain F5 systems, including portions of BIG-IP source code and vulnerability-related information. [8][9][10] The concern was not only what happened inside F5. It was what stolen vendor intellectual property could enable against the global installed base over time. [9][10]

Public notices characterized the threat actor as highly sophisticated and nation-state aligned, but the primary government and vendor advisories did not publicly attribute the activity to a specific named group. [8][11] For the purpose of executive risk decisions, the more durable point is not the label. It is the risk mechanism: vendor intellectual property loss can reduce attacker cost and accelerate exploitation against widely deployed infrastructure. [9][10]

BIG-IP, as F5’s flagship product family, supports core edge functions such as load balancing and traffic management, and in many environments it also enforces security controls at the edge, such as access controls and application security capabilities. Because BIG-IP is widely deployed across large enterprises and government networks, any supplier incident that could improve attacker understanding of its internals creates downstream relevance for many organizations. [9][11]

Companies should care about this compromise for two reasons. First, this incident was not framed as only “a vulnerability in a product.” The reported concern was that an intruder accessed certain F5 internal systems and obtained files that included portions of source code and vulnerability information. This could give an attacker technical advantage in identifying or weaponizing weaknesses against the installed base. [9][10] Second, because BIG-IP often sits at or near the edge of enterprise environments, weaknesses in exposed or poorly managed deployments can become high-impact entry points. This downstream concern is one reason U.S. government guidance pushed agencies to inventory and mitigate affected F5 devices. [11][9]

Sequence of events

F5 published an incident notice describing persistent access by a highly sophisticated threat actor and the downloading of files from certain F5 systems. [8]

The Canadian Centre for Cyber Security summarized that impacted systems included BIG-IP product development and engineering knowledge management platforms. It has also noted that a small percentage of customers may have had configuration or implementation information involved. [8] FedRAMP described the event as exfiltration of files that included a portion of BIG-IP source code and vulnerability information, and highlighted the risk of technical advantage for exploitation. [9] Unit 42 also described theft of BIG-IP source code and information about undisclosed vulnerabilities, reinforcing the long-tail risk framing. [10] CISA issued Emergency Directive 26-01 with required actions for federal agencies to mitigate risk associated with F5 devices. [11]

Anatomy of compromise (why supplier intellectual property theft changes the threat model)

Supplier access and persistence. Public summaries indicate the threat actor maintained access to certain supplier systems over time. Persistence matters because it enables selective collection of high-value artifacts, including source code, vulnerability documentation, and engineering knowledge bases. [8][9]

Exfiltration. When source code and vulnerability information are stolen, risk becomes asymmetric. The attacker can use privileged knowledge to identify weaknesses faster, develop exploit chains, and target environments that lag patching or are misconfigured. This does not guarantee immediate exploitation, but it increases the likelihood and potential speed of follow-on exploitation campaigns targeting the supplier’s customer base. [9][10]

Downstream exposure. BIG-IP products are widely used for traffic management, access control, and availability. In practice, these systems often sit at or near the edge, which makes them attractive as initial access points because compromise can provide visibility into traffic flows and a path toward high-value internal systems. [11][9]

Impact and implications (business, technical, geopolitical)

From a business perspective, supplier compromise events create a long tail of assurance work. Customers, regulators, and internal leadership require proof that products remain safe to operate, and organizations must plan patching, monitoring, and communications at scale. [11][9] Technically, theft of vulnerability information and source code changes the attacker cost model. It can reduce time to exploit and enable more tailored exploitation techniques. [9][10] Strategically, nation-state aligned activity against infrastructure vendors fits a pattern of long- horizon enablement that can support surveillance, pre-positioning, and future leverage. [10][8] From a policy and compliance standpoint, government directives elevate urgency and can drive rapid mandated actions across regulated environments. [11][9]

Analyst assessment

Analysts assess with moderate confidence that the primary customer risk driver is not immediate compromise from the supplier incident alone, but an elevated probability of follow-on exploitation attempts against exposed and unpatched BIG-IP deployments over the next 6 to 18 months. This assessment is based on public descriptions of source code and vulnerability information theft and the operational logic that such theft can accelerate exploitation tooling development and targeting efficiency. [9][10] Controls that measurably reduce risk Organizations can measurably reduce risk by maintaining an accurate edge inventory and reducing exposure, including identifying BIG-IP assets, limiting or eliminating public exposure of management interfaces, and enforcing segmentation. [11] Patch and mitigation validation should be evidence-based, including version confirmation and configuration hardening where applicable. [11][9] Given the long-tail enablement risk, exploit-readiness monitoring becomes a practical requirement: increased detection for anomalous access patterns and configuration changes on edge infrastructure, with clear escalation paths. [11] Supplier assurance should also move from attestation to artifacts, including incident closure documentation and security posture statements, paired with independent monitoring to validate exposure over time. [9][8] Finally, tabletop exercises should explicitly include supplier intellectual property theft scenarios, because the response burden tends to arrive later in the form of accelerated patch windows, renewed scanning, and threat hunting reprioritization. [9][11]

Spotlight: Scattered Spider and the human supply chain

Scattered Spider is a financially motivated intrusion group publicly described as breaking into organizations by attacking the human and process layer of identity security, not only the technical perimeter. [12][14]

Public joint advisories describe the group using voice-based social engineering, including calling or impersonating employees, and exploiting trusted relationships with IT help desks, including outsourced or contracted support, to trigger password resets, enroll new authentication methods, or otherwise take over accounts. [12][13][14] In plain terms, they are reported to use legitimate recovery and support processes as the attack path and then move quickly toward high-value systems once they have access. [12][14]

The reason this matters at enterprise level is simple: this is a supply chain problem in disguise. The “supplier” is often your help desk function or identity support vendor, and the “product” is credential authority. If an attacker can persuade a help desk to reset an executive or administrator account, they can bypass many technical defenses and gain privileged access quickly, creating rapid business impact and forcing costly response work to determine what was accessed and what controls must be restored. Public advisories emphasize that this risk grows when support is outsourced or distributed and when verification rigor is inconsistent, because a single weak workflow can become repeatable across accounts and environments. [12][13][14]

Why this belongs in a supply chain report

Supply chain risk is often described as software and vendors. In practice, it also includes outsourced business processes that control access. Public advisories describe Scattered Spider abusing trusted relationships with contracted IT help desks and using voice-based social engineering to convince help desk personnel to reset passwords and modify multi-factor authentication. This is supply chain compromise by process: the supplier is the support function, and the product is credential authority. [12][13][14]

What is publicly reported about the tradecraft

Public reporting describes Scattered Spider’s approach as deliberately human-centered, designed to turn normal support and recovery processes into an access path. The Australian Cyber Security Centre advisory summarizes tactics, such as voice-based social engineering, mobile phishing, and abuse of trusted relationships with contracted IT help desks. [12] In practical terms, joint advisories report that operators call or impersonate employees, persuade support staff to reset passwords, and alter multi-factor authentication settings, not by exploiting technical vulnerability, but by exploiting the reality that help desks are designed to restore access quickly. [12][14] The same public reporting also highlights how the group sustains advantage once inside. Advisories describe operators searching email and collaboration platforms to understand how defenders are responding and to track response activity. They also describe behavior consistent with maintaining access, including creating new identities and manipulating authentication processes in ways that can make lockout and recovery harder for defenders. [12][14]

The combined effect is that initial access may look ordinary, but the impact can escalate quickly because the attacker is operating inside the organization’s identity and communications fabric. [12][14]

Business implications

From a business perspective, Scattered Spider’s relevance is that the attack surface is not only technology. It is process. When help desk and account recovery workflows can be manipulated, an adversary can bypass expensive security tooling and obtain privileged access through legitimate channels. Public advisories emphasize that this risk is amplified when identity support is outsourced or distributed across multiple vendors, because verification standards vary and speed is often prioritized over rigorous confirmation. [12][13][14] The result is that a single successful social engineering event can trigger enterprise-wide impact, including disruption, potential data exposure, and a long assurance cycle to determine what the attacker accessed and what controls were restored. [12][14]

Defensive posture that actually works

Analysts assess with high confidence that reducing this risk depends on treating account recovery as a privileged change process. Public guidance recommends stronger verification for help desk actions, limiting who can reset credentials or modify authentication methods, and using phishing-resistant multi-factor authentication for recovery and administrative workflows. [12][14] Monitoring should reflect the reported tradecraft. Identity events such as new device enrollment, authentication method changes, and unusual reset activity are best treated as high-signal security events and, where possible, correlated with help desk tickets and call records to distinguish legitimate recovery from adversary-driven changes. [12][14] The goal is to make recovery predictable, auditable, and difficult to abuse, even under time pressure. [12][14]

Case 4: Miljödata Sweden and public sector concentration risk

Public sector supply chains have a distinctive fragility: high concentration, shared vendors, and legally sensitive personal data held across many entities. In late August 2025, reporting described a suspected ransomware attack on Miljödata, a Swedish software provider used by municipal governments, that affected around 200 municipalities and regions. [15][16] The incident disrupted HR-related systems used for sick leave and other employee administration, illustrating how a supplier incident can create broad governance disruption when a single provider sits on essential public workflows. [15][16]

Executives should care about this incident because it is one of the clearest forms of third-party concentration risk. Even strong internal security cannot fully offset failure at a shared vendor that supports essential processes and handles sensitive administrative data. When one supplier supports many organizations, a single compromise can trigger operational interruption and high- cost assurance work across every customer at once, including crisis communications and regulatory obligations. Reporting on the Miljödata incident underscores how supply-chain ransomware can become a continuity event, not just an IT incident, particularly in sectors where redundancy is limited and switching costs are high. [15][16]

Sequence of events

The Record reported that Miljödata’s CEO said the attack was detected on a Saturday and that around 200 municipalities and regions were affected. [15] The same reporting noted that affected workflows included items such as medical certificates, rehabilitation plans, and work-related injury information, based on local government statements cited in coverage. [15] The Register reported municipal governments were knocked offline after ransomware hit the supplier and highlighted operational disruption and extortion activity associated with the incident. [16]

Anatomy of compromise (public sector cascade)

Supplier dependency. Municipalities rely on specialized providers for HR administration and compliance-related reporting. When that provider is disrupted, local governments lose workflows that support employee management and require administrative processes. [15][16]

Concentration. When a single supplier serves a large share of a sector, the incident becomes a multi-organization event by design. This is systemic dependency risk, not simply a failure of any one municipality. [15][16]

Data sensitivity. HR systems can contain personal identifiers and sensitive administrative information. Even when attackers pursue extortion rather than broad publication, the possibility of exposure can still trigger legal, regulatory, and public trust consequences. [15][16]

Impact and implications (business, technical, geopolitical)

Continuity. Disruption to municipal HR systems can affect staffing administration and the ability to maintain normal operations, with compounding effects during periods of heightened public demand. [15][16] Public trust: Municipalities face a high bar for transparency and assurance. Even partial exposure or prolonged disruption can create durable reputational harm and sustained public scrutiny. [15][16] Geopolitics: This case illustrates that adversaries do not need to directly target a national ministry to create strategic effect. Disrupting an IT supplier supporting many local governments can create widespread friction and resource diversion across a public sector ecosystem. [15][16]

Controls that measurably reduce risk

Public sector entities reduce systemic exposure when they treat concentrated vendors as critical dependencies rather than standard third parties. That begins with sector-wide supplier mapping to identify which providers represent concentration risk and to align oversight accordingly. [15][16] Resilience requirements should be evidence-based, including demonstrated offline backups, recovery time objectives, and tested incident response coordination with customers. [15][16] Data segmentation and tenant separation help limit cross-entity exposure when one provider serves many municipalities. Crisis communications should also be pre-planned, because public disclosure obligations and unified messaging become part of the operational burden during multi-entity incidents. [15][16]

Cross-case analysis

Trust leverage as the defining pattern Across these events, the defining feature was not malware novelty. It was trust leverage. Attackers repeatedly selected pathways where a relatively small action could produce outsized downstream reach. Such as a stolen package maintainer token that allowed code to be published as “legitimate,” an internet-exposed file transfer service that sits on a regulated data corridor, a supplier development environment that holds product blueprints and vulnerability knowledge, an outsourced help desk workflow that can reset identity faster than defenders can respond, or a concentrated municipal provider that supports dozens or hundreds of public entities. In each case, the attacker’s advantage came from positioning upstream of many victims, then allowing normal business connectivity to amplify the impact.

Trust pathways that drove 2025 supply chain impact The most useful way to interpret 2025’s supply chain incidents is by the trust pathway the adversary exploited, because that trust pathway determines both blast radius and the most effective controls. In the software assembly trust pathway, dependency registries and automated builds acted as force multipliers. When a malicious update entered the ecosystem, the speed of modern development pipelines meant compromise could propagate faster than human review cycles could realistically react, and the downstream risk quickly shifted from “bad code” to stolen secrets and identity compromise.

In the shared platform trust pathway, managed file transfer and similar business rails proved again that boundary systems carry disproportionate risk. These services are designed to move sensitive data across organizational boundaries, so when a remote execution condition exists or a vendor is compromised, the incident naturally becomes multi-victim and legally complex.

In the supplier enablement trust pathway, the risk profile changed from immediate incident response to long-tail exposure management. When adversaries obtain supplier intellectual property, such as source code and vulnerability information, they reduce their cost to find and weaponize weaknesses and may accelerate exploitation against the installed base over time. This is why supplier compromise can create strategic risks even when there is no confirmed widespread exploitation in the moment.

In the process and identity trust pathway, Scattered Spider highlighted a hard truth: account recovery and help desk procedures function as a supply chain for credential authority. When those processes are manipulated, attackers can bypass technical safeguards, gain privileged access quickly, and sustain advantage by operating inside legitimate workflows.

Finally, the public sector concentration trust pathway made the systemic nature of third-party dependency visible. Specialized vendors supporting many municipalities can become single points of disruption, turning an attack on one supplier into a continuity event for an entire sector.

Amplifiers that increased blast radius Several amplifiers repeatedly increased blast radius across the cases. Credential reuse and long- lived tokens were among the most consistent accelerants. Once secrets were stolen, attackers could move laterally across code repositories, cloud environments and operational platforms without needing noisy exploitation, expanding impact well beyond the original entry point.

Automation compounded the problem on both sides: build systems and scripts consumed malicious updates rapidly, while attackers automated republishing, propagation, and credential harvesting at scale. Visibility gaps then determined the length and cost of the incident. Organizations that could not quickly answer where a dependency was used, which business workflows depended on a vendor service, or which accounts had exposure, inevitably faced slower containment, broader precautionary resets, and more difficult assurance conversations with customers, regulators, and leadership.

Taken together, these cases reinforce a practical conclusion for executives: supply chain compromise is best governed by protecting and continuously validating the trust paths that connect systems, vendors, and people. The organizations that reduce risk most effectively are those that can map dependencies, minimize credential leverage, harden boundary platforms, and prove closure with evidence rather than intention.

Conclusions

Supply chain compromise should now be understood primarily as a cascade problem. The decisive driver of cost is not whether an attacker used novel tools or sophisticated malware, but whether a single point of compromise triggered downstream obligations at scale. Once a shared component or service is compromised, organizations inherit the consequences: operational disruption, urgent investigations across multiple teams and environments, customer and partner notifications, regulatory reporting, and the slow, expensive work of restoring confidence. Time to identify exposure, time to rotate credentials, and time to validate remediation are the operational metrics that separate contained incidents from cascades. In these incidents, the technical event is often only the opening chapter. The financial and reputational impact accumulates in the weeks and months that follow, as leaders are forced to answer hard questions about exposure, containment, and whether the organization can prove closure.

That is why the practical unit of risk is no longer “the vendor” in the abstract. It is the trust path the vendor, component, or process controls. In 2025’s most consequential events, adversaries repeatedly targeted the same categories of trust paths because they offered leverage. Code distribution authority in open-source ecosystems can quietly insert malicious changes into software assembly lines. Data transfer platforms can expose sensitive files and provide a foothold across partners. Supplier development environments can yield privileged knowledge that shortens time to exploit across the installed base. Identity recovery workflows can be turned into a fast lane to privileged access when help desks, contractors, or account recovery processes are manipulated. Concentrated vendors, especially those embedded into critical workflows, can become single points of disruption for entire sectors.

The organizations that performed best in these conditions shared a specific capability: they could establish clarity faster than the attacker could create confusion. They were able to map what depended on what, where affected components were used, and what was exposed externally. They rotated credentials decisively, rather than debating whether rotation was “necessary,” because the cost of delay was higher than the cost of inconvenience. They validated remediation, meaning they did not stop at applying a patch or removing one malicious package. They confirmed that environments were rebuilt from known-good sources, that secrets were invalidated, and that there was defensible evidence showing the risk had been reduced.

That speed and discipline reduced operational downtime and, just as importantly, preserved credibility with customers, regulators, and internal leadership.

This is also where traditional vendor assurance breaks down. Questionnaires and policy attestations rarely answer the questions that matter in a real supply chain incident: are critical systems patched, are high-risk services exposed, are privileged access paths controlled, can the supplier demonstrate secure development practices, and can they prove what happened and what was fixed. The shift executives should demand is from promises to evidence. That evidence includes verifiable patch status for internet-facing services, clear access control design for privileged environments, incident closure artifacts that show scope and root cause, and measurable recovery capabilities such as tested backups and realistic recovery time objectives. In other words, assurance should be grounded in what can be validated, not what can be stated.

Looking ahead, analysts assess with moderate to high confidence that adversaries will continue to pursue high-leverage entry points in 2026 because the incentives remain unchanged. One compromise that yields many victims is efficient, scalable, and difficult for defenders to bound quickly. The targets will vary, but the logic will not: attackers will keep aiming for the trust mechanisms that sit upstream of many organizations at once. Organizations, that treat those trust paths as business-critical assets, measure their exposure, and demand evidence-based assurance, will be best positioned to reduce blast radius and respond with authority when the next cascade begins.

Recommendations

The recommendations below are framed as an executive advisory and are intended to be measurable and auditable. Analysts note that organizations benefit from treating dependency governance as a business control, not an engineering preference. In practice, that typically means pinning dependency versions for production systems and routing upgrades to high-risk libraries and build scripts through a controlled process with clear approval gates, so leaders can later demonstrate what changed, when it changed, and why it was accepted.

Analysts further assess that this governance is strongest when it is anchored in an authoritative inventory. Maintaining a current software bill of materials, a living record of critical dependencies and where they run across build pipelines and production services, materially improves response credibility. In real supply chain events, organizations that can rapidly answer where a component is used, which versions are present, and what has been built or deployed during the exposure window tend to contain faster and communicate with greater confidence.

Credential leverage continues to be a decisive risk factor. Analysts note that replacing long-lived registry and code tokens with scoped, short-lived credentials, and treating rapid secret rotation as standard procedure after registry compromise signals or vendor advisories, reduces attacker optionality. This is particularly relevant where credential harvesting is suspected, because it directly disrupts follow-on access into source code, cloud environments, and build systems.

Analysts also observe that hardening continuous integration and delivery pipelines helps prevent build systems from becoming propagation engines. Organizations that isolate build identities from individual user identities, restrict outbound network access from build environments, and monitor for unauthorized workflow and configuration changes generally reduce the likelihood that a compromised developer account or poisoned dependency translates into production exposure.

Boundary platforms remain a recurring concentration point. Analysts assess that managed file transfer systems and similar internet-facing services warrant special governance because they sit on regulated data corridors and partner exchange pathways. Organizations typically reduce risk by maintaining a clear inventory of externally reachable platforms, enforcing rapid patching with verification, and validating configuration hardening as a condition of continued operation.

On third-party risk, analysts note that supplier governance tends to perform best when vendors are tiered by systemic impact rather than spend. Concentrated suppliers and vendors that sit on critical trust paths generally warrant stronger evidence requirements. In this model, assurance shifts from questionnaires to proof, including verified patch status for exposed systems, access control design for privileged environments, incident closure artifacts, and measurable recovery capabilities.

Identity recovery processes increasingly function as a practical supply chain for credential authority. Analysts assess with high confidence that organizations reduce exposure when account recovery is treated as a privileged change process. Common controls include dual verification for account recovery, phishing-resistant multi-factor authentication for help desk actions, and monitoring identity changes such as new device enrollments and authentication method resets as security events.

Operational resilience is another differentiator. Analysts note that vendors and critical suppliers provide more meaningful assurance when they can demonstrate tested backup and recovery capabilities, realistic recovery time objectives, and tabletop exercises that include customers, not only internal documentation. Resilience is typically most credible when it has been rehearsed under constraints.

Finally, analysts emphasize the value of evidence of closure. Organizations that require post- incident artifacts proving remediation and verification, such as rebuild evidence where applicable, documented secret rotation, and exposure validation, tend to preserve credibility with customers and regulators. Continuous external monitoring, including independent security ratings and attack surface monitoring, further supports this by validating supplier posture over time and detecting security drift early.

Prognosis and predictions for 2026 and beyond

Looking into 2026, analysts expect the supply chain to remain the preferred terrain for scaling cyber risk, because it offers leverage. The defining contests will not be limited to “better malware” or “more zero-days.” They will center on who controls the trust layer: the credentials that publish code, the platforms that move regulated data, the supplier environments that shape widely deployed infrastructure, and the human processes that can reset identity in minutes.

Analysts assess with moderate confidence that token-focused supply chain operations will continue to increase. The logic is straightforward: credential harvesting yields durable access across cloud environments, software registries, and code repositories, and it can be automated at low cost. Once tokens and keys are stolen, attackers can move laterally without noisy exploitation, and they can republish or reconfigure systems in ways that are difficult for organizations to detect quickly and even harder to unwind cleanly.

Analysts assess with moderate confidence that managed file transfer and similar boundary platforms will remain priority targets. These systems sit on concentrated, regulated data corridors and are often kept internet-accessible to serve business workflows. That combination, high-value data plus external exposure plus deep integration into partner operations, makes them a recurring source of multi-victim incidents when vulnerabilities emerge or when suppliers are compromised.

Analysts assess with moderate confidence that supplier intellectual property theft will become a more visible national security concern. When source code, engineering knowledge, or vulnerability information is stolen, it can accelerate exploit development and enable prepositioning against critical infrastructure and large enterprises. The strategic value is not only immediate access, but a long tail of advantage: faster discovery of weaknesses, stealthier exploitation, and greater optionality for future campaigns.

Analysts assess with high confidence that identity recovery and help desk compromise will persist as a dominant initial access pattern. This pathway succeeds because it bypasses many technical defenses and exploits business processes that are difficult to redesign quickly, especially when support is outsourced, distributed globally, or optimized for speed over verification rigor. In many organizations, the “front door” is no longer a firewall. It is account recovery.

Finally, analysts assess with moderate confidence that public sector concentration incidents will expand. Municipalities and regional governments often share specialized vendors with limited redundancy, while budget and staffing constraints slow resilience improvements. When a single supplier supports many entities, an attacker can cause broad disruption and public trust damage through one compromise, turning ransomware from an IT event into a continuity event.

Across all five predictions, the common pattern is the same: adversaries will keep choosing entry points that produce many victims from a single foothold. The organizations that perform best in 2026 will be those that treat these trust paths as business- critical assets, measure exposure continuously, and can demonstrate evidence of closure when incidents occur.

Appendix A: Terms and acronym expansions

CI/CD. Continuous integration and continuous delivery. Automated processes that build, test, and deploy software.

MFA. Multi-factor authentication. A login method that requires more than one proof of identity, such as a password plus an authenticator code.

MFT. Managed file transfer. Software, used to securely exchange files between organizations and systems.

RCE. Remote code execution. A security flaw that lets an attacker run commands on a system from a remote location.

SBOM. Software bill of materials. A structured inventory of software components and dependencies used to build a product.

Token. A secret value used for authentication to services such as code repositories, package registries, or cloud systems.

Appendix B: Sources

[1] AWS Security Blog, “Defending against supply chain attacks like Chalk/Debug and the Shai- Hulud worm,” Oct 2, 2025. hxxps://aws[.]amazon[.]com/blogs/security/defending-against-supply-chain-attacks-like-chalk- debug-and-the-shai-hulud-worm/

[2] AWS Security Blog, “What AWS Security learned from responding to recent npm supply chain threat campaigns,” Dec 15, 2025. hxxps://aws[.]amazon[.]com/blogs/security/what-aws-security-learned-from-responding-to- recent-npm-supply-chain-threat-campaigns/

[3] Palo Alto Networks Unit 42, “Shai-Hulud Worm Compromises npm Ecosystem in Supply Chain Attack,” updated Nov 26, 2025. hxxps://unit42[.]paloaltonetworks[.]com/npm-supply-chain-attack/

[4] Cleo, “Cleo Product Security Advisory - CVE-2024-50623,” Dec 10, 2024. hxxps://support[.]cleo[.]com/hc/en-us/articles/27140294267799-Cleo-Product-Security- Advisory-CVE-2024-50623

[5] Cleo, “Cleo Product Security Update - CVE-2024-55956,” Dec 14, 2024. hxxps://support[.]cleo[.]com/hc/en-us/articles/28408134019735-Cleo-Product-Security- Update-CVE-2024-55956

[6] Reuters, “Hertz says hackers stole its customer data,” Apr 14, 2025. hxxps://www[.]reuters[.]com/technology/cybersecurity/hertz-says-hackers-stole-its-customer- data-2025-04-14/

[7] Huntress, “Threat Advisory: Cleo software actively being exploited in the wild,” Jan 6, 2025. hxxps://www[.]huntress[.]com/blog/threat-advisory-oh-no-cleo-cleo-software-actively-being- exploited-in-the-wild

[8] Canadian Centre for Cyber Security, “AL25-014 Security Incident impacting F5,” Oct 15, 2025. hxxps://www[.]cyber[.]gc[.]ca/en/alerts-advisories/al25-014-security-incident-impacting-f5

[9] FedRAMP, “Responding to CISA Emergency Directive 26-01,” Oct 15, 2025. hxxps://www[.]fedramp[.]gov/2025-10-15-responding-to-cisa-emergency-directive-26-01/

[10] Palo Alto Networks Unit 42, “Nation-State Actor Steals F5 Source Code and Undisclosed Vulnerabilities,” Oct 16, 2025. hxxps://unit42[.]paloaltonetworks[.]com/nation-state-threat-actor-steals-f5-source-code/

[11] CISA, Emergency Directive 26-01, “Mitigate Vulnerabilities in F5 Devices,” Oct 15, 2025. hxxps://www[.]cisa[.]gov/news-events/directives/ed-26-01-mitigate-vulnerabilities-f5-devices

[12] Australian Cyber Security Centre, “Scattered Spider,” joint advisory page, updated Jul 29, 2025. hxxps://www[.]cyber[.]gov[.]au/about-us/view-all-content/alerts-and-advisories/scattered- spider

[13] Canadian Centre for Cyber Security, “Joint cyber security advisory on Scattered Spider,” Jul 29, 2025. hxxps://www[.]cyber[.]gc[.]ca/en/news-events/joint-cyber-security-advisory-scattered-spider

[14] CISA, “Scattered Spider” advisory AA23-320A, updated Jul 29, 2025. hxxps://www[.]cisa[.]gov/news-events/cybersecurity-advisories/aa23-320a

[15] The Record (Recorded Future News), “Hundreds of Swedish municipalities impacted by suspected ransomware attack on IT supplier,” Aug 27, 2025. hxxps://therecord[.]media/sweden-municipalities-ransomware-software

[16] The Register, “Sweden's municipal governments knocked offline after ransomware crooks hit IT supplier Miljödata,” Aug 28, 2025. hxxps://www[.]theregister[.]com/2025/08/28/sweden_council_ransomware/