GitHub left reported malware imitation up for 23 days, removed it minutes after a Hacker News post

A malware report that sat unanswered for 23 days

On 31 August, a customer tipped off the developer of Easy Data Transform that a project on GitHub was posing as their data-wrangling product. According to the vendor's account on successfulsoftware.net, which reached the front page of Hacker News on 24 September, the repository borrowed the product's name and logo without permission.

The vendor says they reported the project to GitHub the same day and received an automated acknowledgment. Nothing further appears to have happened for weeks.

What the fake installer did

A colleague of the vendor downloaded the Mac disk image hosted in the repository and scanned it on VirusTotal, where a large number of engines flagged it as malicious. Digging further with IsoBuster, they found that the installer's background image had been swapped for one telling anyone running it to disregard any security warnings their machine displayed — a piece of social engineering layered on top of the payload itself.

The vendor says they passed all of this to GitHub on 10 September. As of 23 September, they had heard nothing beyond the original automated reply: 23 days after the first report, a repository distributing flagged malware under their brand was still live.

The likely audience, in the vendor's own reading, is people hunting for an unpaid copy of a commercial tool. They write that they have limited sympathy for users who get compromised that way, but object to their work being used as bait. Their practical advice is simple: get software from the vendor whenever possible.

Ten minutes after Hacker News

The post was picked up by Hacker News on 24 September. According to the author's update, GitHub took the offending page down roughly ten minutes after the story hit the site's front page. The author's conclusion, offered with visible sarcasm, is that front-page coverage appears to be the most reliable route to basic support from GitHub, and that the platform can move quickly when it chooses to.

The account is one vendor's version of events and contains no response from GitHub beyond the automated email. But the timeline it describes — three weeks of silence followed by near-instant removal once the story became public — is the part that should concern anyone who depends on GitHub's abuse-reporting pipeline.

Why it matters

GitHub functions as default infrastructure for how code and tools are found, evaluated and downloaded. A repository that imitates a commercial product while shipping a malware-flagged installer corrodes that trust, and it does double damage: users end up with compromised machines, and the impersonated vendor absorbs the reputational fallout.

The episode also exposes an asymmetry in escalation. Small vendors and independent researchers cannot count on front-page coverage, and if the effective path to a takedown runs through public pressure, most well-documented reports will never get that push. The vendor was left weighing a DMCA takedown request as a separate lever — a copyright mechanism pressed into service against what was, on the evidence described, primarily a malware distribution problem.

For developers, the lesson is narrower but useful: confirm that a download comes from the vendor's or project's own channel, treat unofficial mirrors of commercial tools with suspicion, and assume that a platform report, however thoroughly documented, may sit in a queue for a long time.