Attackers exploited a GitHub Actions workflow flaw to publish a malicious version of element-data — a Python package with over one million monthly downloads — to PyPI and Docker. Version 0.23.3 remained active for approximately 12 hours, harvesting cloud credentials, SSH keys, API tokens, and .env secrets from every environment where it ran. CI/CD pipelines were the primary target: high-privilege, broadly accessible, and rarely treated as an active threat surface

Overview

You may not be directly affected by the element-data supply chain attackthat compromised the open-source Python package last weekend, but when you think of how it happened, in spite of a protected perimeter and patched endpoints, you might step back and give it some thought.

The popular Python package with over one million monthly downloads was quietly weaponised, and for roughly 12 hours, anyone who downloaded or updated to element-data v0.23.3, may have inadvertently installed a backdoored build that has the potential to exfiltrate cloud provider keys, database credentials, SSH keys, and API secrets, without detection. Not even by scanners!

The attackers didn't crack a server. They hijacked a workflow.

The Attack Nobody Sees: Pipeline Poisoning

The category of software supply chain security failures most overlooked by security teams is called pipeline poisoning, which is the exploitation of automated CI/CD workflows to inject malicious code directly into the trusted build process rather than attacking the software itself from the outside.

Why this attack is a wake up call for application security experts is because the backdoor passed automated checks and moved past every defence that is typically deployed at the dependency layer.

Why CI/CD Environments Are a Goldmine

CI/CD runners in the pipeline are engineered to access everything they require – AWS IAM keys, database connection strings, Kubernetes tokens and API credentials – to deploy software at scale. That means, if your organization runs the malicious package in the pipeline, the credential theft will most likely not be limited to one developer’s machine.

According to Verizon’s 2025 Data Breach Investigations Report, 30% of breaches involve a third party software vendor or supply chain partner, which is a two-fold increase from last year.

The element-data incident highlights both the high value and the lack of defences of software supply chains.

What You Must Do in the Next 72 Hours

If your organisation uses element-data, abstract threat awareness is not enough. This is an active incident posture.

Our security experts recommend  you to conduct a comprehensive audit of your lateral environment, identifying and querying your packages, eradicating the malicious version, hunting for indicators of compromise (IoCs) and rotating credentials to revoke the old values.

You Cannot Secure What You Cannot See… Or Can You?

It’s important to acknowledge and understand that your organisation’s attack surface isn’t limited to just the approved package list, but includes every dependency the packages carry.

Every open-source Python package your organisation uses has a provenance chain. Most security teams can name their direct dependencies. But few can tell you, in real time, which of those dependencies changed last weekend, which transitive packages carry a known CVE, or which build pipeline was touched by an unverified contributor.

That visibility gap is where attackers operate. Closing it is a security architecture decision, not a developer’s task.

Stop Flying Blind on Your Dependency Graph

Flyingduck’s Software Bill Of Materials (SBOM) platform bridges this visibility gap and changes the way your security team and developers work. Our platform offers a queryable, continuously updated platform with a real-time inventory of every package, every dependency layer, and every known vulnerability across the entire codebase. Our aim – to help security-mature organisations detect the next pipeline poisoning attack at the commit level, before it reaches production.

Whether it is a zero-day or a software supply chain compromise, Flyingduck’s SBOM platform detects the vulnerability in real-time and maps both direct and indirect dependencies so your organisation doesn’t need to manually audit manifests to track exposure.

What sets our SBOM platform apart from traditional SCA scanners, is a baseline requirement for all CISOs managing CI/CD pipeline exposures at scale – a smart, code-level remediation guidance layer that allows developers to act immediately without waiting for a security ticket to cycle back.

Book a demo with Flyingduck to find out how many of your current projects might be carrying a risk you haven't inventoried yet.