Someone Poisoned Hundreds of Python Repos. The Trick Is 2,500 Years Old.

Key Takeaways

• •GlassWorm used stolen GitHub tokens to inject malware into hundreds of Python repos — Django apps, ML research, PyPI packages
• •The attack targeted the software supply chain: poisoning trusted code that developers install without inspecting
• •Supply chain attacks have grown 742% since 2019 — from 216 incidents to an estimated 35,000 in 2026
• •Ken Thompson's 1984 lecture 'Reflections on Trusting Trust' warned that compilers themselves could be trojaned
• •The XZ Utils backdoor (2024) showed how a patient attacker can spend years gaining trust before striking

Source: Sonatype State of Software Supply Chain, ReversingLabs

Timeline

Let's start with a story everyone knows.

Around 1200 BC, the Greeks had been besieging Troy for ten years. The walls were impenetrable. The defenders were stubborn. Brute force wasn't working.

So the Greeks built a wooden horse, hid soldiers inside it, and left it at the gates as a "gift." The Trojans, believing the Greeks had given up, wheeled the horse inside the city walls. That night, the soldiers climbed out and opened the gates. Troy fell.

The lesson isn't about horses. It's about trust. The Trojans didn't inspect the gift because it appeared to come from a legitimate source — a surrender offering. The attack worked because the delivery mechanism was trusted.

Hold that thought. Now it's March 2026.

The Greeks couldn't breach Troy's walls with force. So they built a wooden horse. GlassWorm didn't breach GitHub's security. It used stolen tokens — legitimate keys — to walk right in. The strategy is 3,200 years old. It still works.

Security researchers have identified an ongoing malware campaign called GlassWorm. The attack vector: stolen GitHub tokens are being used to inject malicious code into hundreds of Python repositories. Not random repos. Trusted ones. Django applications. Machine learning research code. Streamlit dashboards. PyPI packages — the packages that developers install with a simple `pip install` command, trusting that the code inside is safe.

The attackers didn't hack GitHub. They didn't find a zero-day in Python. They didn't need to. They had stolen personal access tokens — the cryptographic keys that prove identity on GitHub. With those tokens, they had legitimate write access to repositories. They looked like the actual maintainers.

They walked right through the gates.

The injected code was subtle. In many cases, the malicious payload was hidden in seemingly innocent updates — a slightly modified import statement, a new utility function that looked helpful but contained an obfuscated backdoor. The kind of change that would pass a cursory code review. The kind of change that automated CI/CD pipelines would build, test, and deploy without a second thought.

Anyone who pulled the latest version of an affected package got the malware for free.

This isn't new. This is the oldest trick in the book — literally.

Ken Thompson told us in 1984: 'You can't trust code that you did not totally create yourself.' Forty-two years later, the average Python project has 39 dependencies, each with their own dependencies. Nobody creates their code themselves anymore. We all live inside the horse.

In 1984, Ken Thompson — one of the creators of Unix and the C programming language — gave his Turing Award acceptance lecture. He called it 'Reflections on Trusting Trust.' In it, he demonstrated something that still haunts computer science: he showed how you could modify a C compiler to insert a backdoor into any program it compiled, including future versions of the compiler itself. The backdoor would be invisible in the source code. It would only exist in the compiled binary. And it would self-perpetuate.

His conclusion was chilling: "You can't trust code that you did not totally create yourself. No amount of source-level verification or scrutiny will protect you from using untrusted code."

Nobody listened. Not because they didn't care, but because the alternative — writing all your own code from scratch — is impossible in the modern world.

The average Python project has 39 direct dependencies. Each of those dependencies has its own dependencies. A typical web application might pull in 200 to 400 packages when you count the full dependency tree. No developer reads all that code. No team audits every update. The entire ecosystem runs on trust — trust that the person who maintains `requests` or `cryptography` or `django-rest-framework` hasn't been compromised.

GlassWorm exploits exactly that trust.

The evolution of supply chain attacks reads like a slow-motion horror movie.

In 2016, a developer named Azer Koçulu unpublished a tiny npm package called left-pad from the npm registry. The package was 11 lines of JavaScript — it padded strings with spaces. Thousands of projects depended on it. When it disappeared, builds broke everywhere — including React, Babel, and other major frameworks. The incident wasn't malicious, but it revealed something terrifying: the entire JavaScript ecosystem depended on a tower of tiny packages maintained by individuals, with no redundancy and no verification.

In 2020, the SolarWinds attack became the most significant supply chain compromise in history. Russian intelligence operatives (attributed to the SVR's APT29 group) inserted malicious code into an update for SolarWinds' Orion network management software. Because Orion was trusted — installed inside the networks of Fortune 500 companies and US government agencies — the update was deployed automatically. Approximately 18,000 organizations installed the compromised update. The attackers had access to the US Treasury Department, the Department of Homeland Security, and parts of the Pentagon.

They didn't hack 18,000 organizations. They hacked one software vendor, and the update mechanism did the rest.

In 2021, the Codecov bash uploader was compromised. Attackers modified a script that thousands of projects used in their CI/CD pipelines — the automated build-and-deploy systems. Every time a project ran its tests using the compromised Codecov script, it silently exfiltrated environment variables — which often contained API keys, database credentials, and access tokens.

In 2024, something even more disturbing happened. A developer using the pseudonym 'Jia Tan' spent approximately two years contributing to XZ Utils — a critical compression library used in virtually every Linux distribution. Jia Tan was patient. They submitted helpful patches. They reviewed other people's code. They built trust. They eventually became a co-maintainer of the project.

Then they inserted a backdoor that targeted OpenSSH, potentially giving them remote access to millions of Linux servers worldwide. The backdoor was discovered almost by accident — a Microsoft engineer named Andres Freund noticed that SSH connections were taking slightly longer than expected and investigated.

Two years of patience. Thousands of legitimate contributions. All to insert a few lines of obfuscated code.

GlassWorm is the same playbook, accelerated. Instead of spending years building trust, the attackers stole existing trust — in the form of GitHub tokens. Instead of compromising one project, they sprayed malware across hundreds.

The question isn't whether supply chain attacks will continue. They will. The number has grown from 216 documented incidents in 2019 to an estimated 35,000 in 2026 — a 742% increase in seven years, and accelerating.

The question is whether our defenses are evolving as fast as the attacks.

Some progress: GitHub now supports mandatory two-factor authentication for maintainers of popular packages. PyPI has implemented Trusted Publishers, allowing packages to be published only through verified CI/CD pipelines rather than personal tokens. Sigstore provides cryptographic signing for software artifacts — a way to verify that the code you're installing was actually built from the source code you can inspect.

But adoption is slow. Most open-source projects are maintained by volunteers who don't have the time or resources to implement advanced security measures. And the fundamental problem remains: modern software is built on trust, and trust is the thing attackers exploit.

There's something poetic about the fact that we call this category of malware "trojans."

We named the attack after the ancient story because we recognized the pattern. We understood the lesson. And then we built a global software ecosystem that is structurally vulnerable to exactly the same trick — hiding something dangerous inside something trusted.

The Trojans inspected the horse. They debated whether to accept it. Cassandra warned them. Laocoön threw a spear at it. But the horse was beautiful, and it appeared to be a gift, and the Greeks seemed to have left.

Every `pip install` is a wooden horse. Every `npm install`. Every `cargo add`. Every package manager in every language. You're accepting code from strangers, trusting that it does what it says.

Usually it does. Almost always, it does. The open-source ecosystem is one of humanity's greatest collaborative achievements — millions of people building shared infrastructure for free, making it possible for a single developer to build in a weekend what would have taken a team of fifty a decade ago.

But the same properties that make open source powerful — openness, accessibility, shared ownership — make it vulnerable. Anyone can contribute. Anyone can publish. And when the gates are open, the horse can walk right in.

Ken Thompson told us in 1984. We named the attack in the 1990s. We watched SolarWinds in 2020. We caught XZ Utils in 2024. And in 2026, GlassWorm is still using the same trick.

The lesson of Troy isn't that gifts are dangerous. It's that trust, once given, is the most powerful weapon there is.

(Sources: DIESEC, CrowdStrike March 2026 Patch Tuesday, Cyber Security Review, Sonatype, ReversingLabs, Ken Thompson "Reflections on Trusting Trust" 1984)

How did this make you feel?

Recommended Gear

Keep Reading

Cybersecurity

Hackers Now Break Out in 29 Minutes — Kevin Mitnick Took Months

5 min read

Cybersecurity

Deepfakes Went From a Reddit Hobby in 2017 to a State Weapon in 2026

5 min read

Cybersecurity

Two Cybersecurity Experts Were Secretly Running Ransomware Attacks on the Companies They Were Hired to Protect. The History of Double Agents Goes Back Centuries.

8 min read