Most repos hit by the Shai-Hulud worm are still infected a week later, and the obvious fix punishes the victims.

This is a follow-up to my earlier posts, and it is more of an open question than an answer. I have the data, I have a way to act, and I am genuinely unsure that acting is the right call. I could use the community's help thinking it through.

Last week a supply-chain worm got into my GitHub account and repositories. I got out, cleaned up the proper way, and wrote it up.

Then I checked the public list of repositories hit by the same worm, to see how the cleanup was going across the ecosystem. Nearly a week later, most of them are still carrying the live payload.

It is worse than a count

When you look closely, a lot of the owners are clearly trying. But they are missing how this actually works, in two ways that matter:

• Deleting is not removing. They remove the malicious files with an ordinary commit. That takes the payload off the branch tip, but the commit that introduced it is still in history, and the blob is still recoverable by anyone who reverts or checks out the old commit. The only real removal is rewriting history (reset, not revert) and asking GitHub to purge the objects, because the fork network keeps them reachable by SHA.
• One branch is not all branches. They clean the branch they know about and never see the backdated copies the worm planted on other branches, which are still live.

And the part that genuinely worries me: some of these owners are almost certainly opening the infected repository in VS Code or an AI assistant to fix it, which is exactly the trigger that runs the payload again. The act of trying to clean it can re-detonate it.

So: a large number of repositories still carrying a live credential stealer, and a large number of owners and contributors who do not know they are still exposed.

The dilemma

Here is where I am stuck. There are two paths and I do not like either.

Report them to GitHub. Their response is automated and blunt. The repo gets disabled, with no human in the loop, the same hands-off automation that locked me out of my own account last week. And it only happens if a person manually parses the list and reports each repository one by one. The people who get hit are usually victims themselves, including the ones in the middle of trying to clean up. I reported a single repository this week, and the only response was an automated takedown that came back within minutes and never engaged with what I had asked, to remove the payload and help the owner, not punish them. I do not read that as malice; I read it as a platform overwhelmed and under-resourced for this.

Do nothing, and watch a slow-motion mess keep spreading.

I do not think mass-reporting is right. It punishes the wrong people. My instinct is that these owners need to be reached and helped, not taken down. But I do not know the right way to do that at this scale.

What I am actually asking

Two things.

First, a request: please do not go and mass-report these repositories. That is the exact blunt path that hurts the people who are already victims. If you take one thing from this post, let it be that.

Second, genuinely: what is the humane version of this? If you work in security, open source, or trust and safety, I want your thinking. How do you warn and help a large number of unaware maintainers, at scale, without triggering automated punishment against people who were attacked through no fault of their own? Is there a channel for that? Has anyone solved this before?

I will share whatever useful approaches come back, and I will keep helping any individual owner who reaches out. But I would rather think this through with the community than make the call alone.

Ionut-Cristian Florescu, OSS maintainer, creator of Mantine DataTable