By Binarly REsearch
At the end of March last year, the entire cybersecurity community was rocked by the discovery of the infamous XZ Utils backdoor. ‘Jia Tan’, a developer who had spent two years building significant credibility in the project through numerous contributions, inserted a sophisticated backdoor into the xz-utils packages. The discovery sent cybersecurity experts, including the Binarly REsearch team, scrambling to reverse engineer the backdoor to understand its scope and potential impact.
In short, the backdoor was embedded in the liblzma.so library, which is used by the OpenSSH server, and is triggered when a client interacts with the infected SSH server. By hijacking the RSA_public_decrypt function using the glibc’s IFUNC mechanism, the malicious code allowed an attacker possessing a specific private key to bypass authentication and execute root commands remotely.
What really stood out in this story is that the backdoor’s impact wasn’t just theoretical, as malicious xz-utils packages containing the backdoor were distributed by several major Linux distributions, including Debian, Fedora and OpenSUSE. This had serious implications for the software supply chain, as it became challenging to quickly identify all the places where the backdoored library had been included. Within 24 hours, Binarly released XZ.fail, a free static analysis-based tool designed to detect suspicious IFUNC resolvers with near-zero false positives.
In this blog, we share a new finding in the XZ Utils saga: several Docker images built around the time of the compromise contain the backdoor.
At first glance, this might not seem alarming: if the distribution packages were backdoored, then any Docker images based on them would be infected as well. However, what we discovered is that some of these compromised images are still publicly available on Docker Hub. And even more troubling, other images have been built on top of these infected base images, making them transitively infected.
In all, we identified more than 35 images that ship with the backdoor. While this may seem like a small number, we only scanned a small portion of the images published on DockerHub, stopping at second-order images. Additionally, we focused solely on Debian images, as they retain historical data on Docker Hub.
The impact on Docker images from Fedora, OpenSUSE, and other distributions that were impacted by the XZ Utils backdoor remains unknown at this time.
At Binarly, we always strive to deliver meaningful results to our customers, increasing their visibility into real security risks and reducing false positives. To achieve this, we are constantly sharpening our tools to stay ahead of evolving threats and deliver precise, actionable insights. Recently, we collected a massive dataset of nearly 15TB of Docker images, which we successfully used to enhance our secrets-finding capabilities.
Given the effort required to build the dataset, we decided to sharpen other capabilities of the Binarly Transparency Platform, specifically the analyses related to malicious code detections. This suite of automated analyses focuses on common types of modifications, such as anomalies in ELF files and various hooking techniques, including the IFUNC hooking method used by ‘Jia Tan’ to implement the backdoor.
During this process, we discovered that 12 Debian Docker images available on Docker Hub still contain one of the xz-utils backdoor, more than a year after the public discovery of the backdoor.
Table 1. Docker images for Debian that contain the XZ Utils backdoor. All affected images are built for the amd64 architecture.
After this initial discovery, we began to wonder: what about other images that might have been built on top of these compromised Debian images? Unfortunately, the Docker API doesn’t provide a reverse index that maps an image to all the base images using it. Because of this, we decided to build a script that fetches all images present in a Docker Hub repository and checks whether any are based on the compromised Debian images.
Since Docker Hub contains nearly 12 million repositories (each possibly containing hundreds or even thousands of images) it would be infeasible to scan the entirety of it. Therefore, we manually created a list of repositories likely using Debian-based images. This list is far from perfect, as it only includes repositories we found manually or those returned from Google searches using the base image blob hash.
Table 2. Second-order docker images (based on the compromised Docker images) containing the XZ Utils backdoor. The “Latest Tag?” column reports whether the affected tag is the latest available one.
The previous table lists the second-order images containing the XZ Utils backdoor. While some appear to be personal projects, other images may be used in enterprise environments. In a recursive fashion, these images could themselves serve as base images, leading to the creation of impacted third-order images and so on and so forth. Doing such a recursive exploration is the only way to gain meaningful insights into the extent of the backdoor’s propagation within the Docker ecosystem.
Upon discovering this issue, Binarly immediately notified the Debian maintainers and requested removal, but the affected images remain in place.
We only partially agree with this response: while it is true that users should rely on up-to-date images, leaving publicly available Docker images that contain a potential network-reachable backdoor poses a significant security risk. Even if the practical impact of this issue is somewhat limited, given that exploitation requires the backdoor key owners to have network access to the infected device or container with the SSH service running.
Nonetheless, our discovery underscores how even short-lived backdoored builds can remain unnoticed and persist in container registries for a very long time.
Security incidents affecting the software supply chain are more frequent than ever. This is one of the key motivations for building the Binarly Transparency Platform: we want to empower security researchers, product security teams and organizations with the right tools they need to detect and remediate threats effectively.
From day one BTP customers had access to a precise analysis developed by our research team to detect IFUNC-based hooking, which is the same technique used in the XZ backdoor. This is the same technology that powers xz.fail, a free scanning tool that Binarly released to support the broader community and help affected organizations to respond to this threat.
One of the latest additions to our platform, unveiled last week at Black Hat USA, is the integration of YARA rules. Part of this integration is a new Rule Playground designed to help platform users to develop YARA rules. In just a few minutes, organizations can scan their entire software portfolio using YARA rules, whether developed internally or sourced from the broader security community.
The xz-utils backdoor incident demonstrates that even short-lived malicious code can remain unnoticed in official container images for a long time, and that can propagate in the Docker ecosystem. The delay underscores how these artifacts may silently persist and propagate through CI pipelines and container ecosystems, reinforcing the critical need for continuous binary-level monitoring beyond simple version tracking.
