31 August 2026

6 MIN.

Two years of trust, one backdoor: what the XZ-Backdoor teaches us about supply chain risks

In June 2026, more than 200,000 files from the Apple supplier network of Tata Electronics surfaced on the dark web: manufacturing documents, parts lists, and internal communications about the newest iPhone 18 Pro. To date, the attack vector has not been publicly disclosed.

That the initial entry point was provided by a software vulnerability is plausible, but has not been confirmed. How such an attack unfolds can be traced in complete detail through another case: the XZ-Backdoor, CVE-2024-3094.

The case: an invisible backdoor with unrestricted access

In late February and early March 2024, malicious code found its way into release versions 5.6.0 and 5.6.1 of XZ Utils, specifically into the liblzma library, a core compression component used by nearly all Linux distributions and embedded in countless software and build processes.

The injected code manipulated SSH authentication: an attacker with the matching key could have logged in without credentials and executed arbitrary code with root privileges. The vulnerability received the highest possible severity rating (a CVSS score of 10.0), since it enabled complete remote access at the system level, hidden inside a library that simply works in the background and that almost no one inspects.

What is remarkable is the disguise: the code stayed inactive in test and scan environments and only activated in live-production. Anyone who inspected the library saw nothing.

Two years of trust, one discovery by chance

The code was not injected through an external attack, but by one of the official maintainers, operating under the pseudonym “Jia Tan“. What’s genuinely unsettling is this account’s track record. For more than two years, the account delivered unremarkable, helpful contributions, built trust with the overburdened lead maintainer, and gradually gained more responsibility until it was finally granted commit rights and the role of second maintainer. That hard-earned trust ultimately became the tool: it gave “Jia Tan” the access needed to place the backdoor exactly where no one was looking closely anymore.

It was not discovered through an audit or a scanner, but by pure chance. In March 2024, developer Andres Freund noticed during performance testing that SSH logins were consuming unusually high CPU time, and traced the cause. By then, the code had already shipped in rolling-release distributions, just weeks before it would have reached the next long-term support (LTS) releases.

Two very different approaches stand side by side: two years of methodical preparation on one side, and one attentive developer on the other. The attack was a process, the discovery was an accident.

One vulnerability, a thousand affected products

Chance cannot be planned for, and no security concept can be built on the hope that an attentive developer happens to be in the right place at the right time. What can be planned, however, is how quickly such a discovery reaches everyone who has the problem in their own products.

Because the vulnerability itself reaches operational systems quickly. A machine builder updates its engineering workstation or ships an edge gateway. The compromised library reaches the production environment not through a network attack, but through a routine update. It is already part of the system classified as trustworthy before that system ever goes into operation. This is exactly what makes supply chain compromises so dangerous: they bypass every control at the network perimeter.

Avoiding third-party components is not an option, since no product of this class is built today without external libraries. That leaves only the other lever: finding, fixing, and disclosing known vulnerabilities as early as possible. This is exactly where the Cyber Resilience Act (CRA) comes in.

Fix, disclose, trace

Three obligations interlock

Remediation: anyone placing a product on the market must close known exploitable vulnerabilities without undue delay and provide updates free of charge throughout the entire support period. In the XZ-Backdoor case, the patch came from the open-source project itself, even though it would not have been obligated to do so under the CRA.

Disclosure: fixed vulnerabilities must be publicly named, together with all affected components.

And the bill of materials (SBOM): every manufacturer must document and analyze what is actually inside their product.

They only work together: disclosure names the component in which a vulnerability has just been fixed, and the SBOM tells every manufacturer whether that component is in their product. Without SBOM, the disclosure has no effect – neither manufacturers nor operators can determine whether their own products are affected.

The chain only ends with the end user

For the next manufacturer in the chain, the work begins with disclosure. The SBOM analysis shows that a reported vulnerability affects a component in their own product. Whether it is also exploitable is nothing the SBOM can tell. Only an assessment in their own context can clarify whether the affected function is even in use, and whether the component is externally reachable.

If the assessment reveals an exploitable vulnerability, the cycle repeats: fix, ship, and disclose to your own customers. For their manufacturers, it then starts all over again. The chain is only complete once it reaches the end user.

For every party involved, this means monitoring and assessing incoming reports while generating outgoing ones of their own. Two channels that need to be maintained on an ongoing basis. This requires clear defined processes tailored to the company’s own structure.

As a manufacturer of an OT security product, we set up this process ourselves and quickly noticed how different it is from familiar software development. What we learned along the way became our CRA consulting service. We help you fit these workflows into your organization, so implementation holds up in daily practice instead of ending up in a drawer.

Three takeaways

Trust is not a security concept. Two years of unremarkable contributions were enough to earn commit rights on a critical project. The attack went through access control, not against it.

The vulnerability comes through the front door. It reaches the plant via a routine update, as part of the trusted software supply chain.

The chain only holds where handovers are solid. SBOM, assessment, and disclosure only work together if they fit into day-to-day operations with as little overhead as possible. The leaner the process, the more reliable it runs.

What the process does not catch

The CRA ensures that discovered vulnerabilities get fixed and disclosed. What it does not do is bridge the time during which no one knows about the gap. In the XZ-Backdoor case, that window was short. That is not the rule, because many vulnerabilities stay undetected for months or even years. In the Tata Electronics case mentioned at the beginning, the attack vector remains unknown to this day and could lead to further incidents. And sometimes even known gaps can no longer be closed, because many production systems have long been running beyond their support period, with no prospect of updates.

For both of these cases, what’s needed is a layer that does not depend on whether a vulnerability is known or whether the system can still be updated. A structural separation between IT and OT, such as the one edge.SHIELDOR establishes, can help.

By the way, for machine builders who need to secure their shipped products against these risks under the CRA, we developed edge.PSL as a dedicated answer.

Take the first step now

Whether you want to set up your CRA obligations, secure your production, protect your shipped machines, or a combination of these: we’ll work through your starting point together with you.

Author: Dr. Madline Kniebusch

Madline Kniebusch has been working as a Data Scientist at TRIOVEGA GmbH since 2021, brings experience from project management, and has been responsible for the implementation of the Cyber Resilience Act since 2026.

Book your individual meeting