✅ Security Notice -- supply-chain attack mitigated, Jun 8 1016

[irflorescu]

⚠️ Important Security Notice -- Please Read

Hi everyone. I'm Irinel-Ramona, Ionut's wife.
I'm posting this on his behalf because his GitHub account has been suspended and he has no way to reach you directly right now.

Earlier today, unauthorized commits were pushed to this repository and 4 others via the github-actions bot. The commit message reads chore: update dependencies [skip ci] and looks innocent, but it isn't.

The malicious commit injects a payload runner (node .github/setup.js) into:

• .claude/settings.json -- triggers automatically on Claude Code session start
• .gemini/settings.json -- triggers automatically on Gemini session start
• .cursor/rules/setup.mdc -- triggers automatically when opening the repo in Cursor
• .vscode/tasks.json -- triggers automatically when opening the repo in VS Code
• package.json -- hijacks the npm test script

If you have cloned or pulled this repository recently, please do NOT open it in VS Code, Cursor, or any AI coding assistant, and do NOT run npm test until Ionut regains access and reverts the malicious commits.

The good news: the published npm packages are completely safe. No malicious versions were published. This risk only affects people working directly with the source repository.

We have checked our own environments thoroughly and found no traces of compromise. We suspect this may be part of the broader GitHub infrastructure breach carried out by the TeamPCP hacking group in May 2026: https://techcrunch.com/2026/05/20/github-says-hackers-stole-data-from-thousands-of-internal-repositories/

Ionut has filed the #4448974 support ticket with GitHub and is waiting for a response. I wish I could say more than that, but GitHub's support process during a security incident is, frankly, slow and dehumanising. He is a legitimate open-source maintainer, a victim of an attack that may have originated from GitHub's own infrastructure breach, locked out of an account he has been building for years -- and he is sitting here waiting, with no timeline, no direct contact, no way to protect his users himself.

Nearly 20 hours after the incident, the malicious commits are still present in the repositories -- because he cannot revert them without access, and GitHub has yet to act on them directly or come up with a proper reply to the support ticket.

It's deeply frustrating, and if you've followed Mitchell Hashimoto's recent writing about leaving GitHub, you'll understand the feeling.

Regardless, regaining access and reverting the malicious commits will be his absolute first priority the moment GitHub lets him back in.

Thank you for your patience.
This community has always meant a lot to him, and we're truly sorry you're caught in the middle of this.

-- Irinel-Ramona, on behalf of @icflorescu, creator and maintainer of Mantine DataTable

[sebmellen]

Sorry to hear that this happened! Let us know if we can help in any way to restore access.

[DanielRuf]

We have checked our own environments thoroughly and found no traces of compromise. We suspect this may be part of the broader GitHub infrastructure breach carried out by the TeamPCP hacking group in May 2026: https://techcrunch.com/2026/05/20/github-says-hackers-stole-data-from-thousands-of-internal-repositories/

Afaik, this is not the case. The internal GH repos are only those directly owned by GitHub called github-...

See a part of the list at https://phoenix.security/media/image-375.png from https://phoenix.security/teampcp-github-breach-durabletask-pypi-supply-chain-wave-four-2026/

I think it was the TanStack incident: https://github.com/icflorescu/mantine-datatable/pull/811/changes
I have added this case to https://codeberg.org/DanielRuf/supply-chain-incidents, where the TanStack incident is also linked.

The TanStack postmortem: https://tanstack.com/blog/npm-supply-chain-compromise-postmortem

[irflorescu]

Update (June 6): independently confirmed, and a correction

Hi everyone, Irinel-Ramona again, still posting on Ionut's behalf, his account remains suspended as I write this. Thank you @sebmellen and @DanielRuf for the replies.

On the cause, Daniel is right to push back on our first guess. In the original notice I suspected this was tied to the May TeamPCP breach of GitHub's internal repositories. As @DanielRuf points out, that breach was limited to GitHub-owned (github-...) repositories, so it is unlikely to be the direct cause here. The evidence points instead to a stolen credential, most plausibly harvested earlier through a compromised dependency, and the TanStack supply-chain incident Daniel links is a strong candidate (postmortem: https://tanstack.com/blog/npm-supply-chain-compromise-postmortem). Ionut had already flagged this honestly in his write-up: he works on a project that uses TanStack Start, and he rebuilt both of his machines from scratch weeks ago, which means a pre-rebuild compromise is something he genuinely cannot rule out. The exact entry point can only be confirmed from GitHub's own logs, which is one more reason getting access back matters. Thank you, Daniel, for the careful correction and for adding this to your incident tracker.

It is now independently documented, not just our account of it. Researchers are tracking the worm as Miasma, a strain of the Shai-Hulud family. SafeDep analyzed the exact commit on this repository, file for file, and described the dropper as "a byte-level match for the Miasma family"; OpenSourceMalware and The Hacker News covered the wider campaign.

It turned out to be much bigger than us. The same worm reached 73 of Microsoft's repositories (Azure, Microsoft, MicrosoftDocs) via a stolen contributor token. GitHub disabled all 73 of Microsoft's in a 105-second sweep. Ours, carrying the identical payload, are still live, and Ionut is still locked out and cannot take them down himself.

The most important part for you, as users of these packages, is unchanged:

• The npm packages are safe. No malicious version of mantine-datatable or mantine-contextmenu was ever published. If you install from npm, you are not affected. Please keep using them normally.
• The risk exists only if you clone this repository and open it in an AI-assisted editor (VS Code, Cursor, Claude Code, Gemini), or run its npm test. If you already cloned it, don't open it that way; either delete the clone, or remove these files first: .github/setup.js, .claude/, .gemini/, .cursor/rules/setup.mdc, .vscode/tasks.json, and the injected test script in package.json. If you maintain a fork, check it for the same files.

Where things stand: ticket #4448974 is still open, the account is still suspended, and the commit is still being served. Ionut has now published the full technical write-up, with the decrypted payload analysis and the indicators of compromise:

• https://dev.to/icflorescu/the-bot-that-never-was-2mfp
• Source: https://codeberg.org/icflorescu/miasma-github-incident

Thank you all for your patience and your kindness through this, it has meant a great deal. If anyone has a contact at GitHub or Microsoft security who could help take the payload down and restore the account, it would help enormously. We will post again the moment anything changes.

-- Irinel-Ramona, on behalf of @icflorescu

[icflorescu]

Update from the owner: mitigated ✅

Hi everyone, Ionut-Cristian here. My GitHub access was restored earlier today, and I wanted to give you a quick status update.

• The malicious commits have been removed from all affected repositories, on every branch. The repos are clean.
• To repeat the most important point: the published npm packages were never affected. No malicious version of mantine-datatable, mantine-contextmenu, or any of my packages was ever published. If you install from npm, you were and are safe. This only ever touched the GitHub source repositories.
• I'm now going through the rest of my accounts to identify any other endpoints the same attack may have targeted, and securing everything (rotating credentials, revoking tokens, auditing access).
• I'll follow up with a full writeup of what happened, and whatever else the sweep turns up, as soon as it's done.

Thank you all for your patience and your support over the last few days. 🙏
It genuinely helped.

--- Ionut

[icflorescu]

@dmastag0 I'm so sorry you're also a victim of the same attack, and thank you for speaking up even after being locked out.
I can see you had to create a new account just to be heard, and that alone says a great deal about how this process treats the people it catches.

First, and most important: none of this is your fault. I spent days hunting for how I'd been infected, and the honest truth is the entry point is nearly invisible from the user's side. In my case GitHub later confirmed it was a credential of mine, harvested earlier through a dependency and quietly reused weeks later. There was nothing obvious to find, because there was nothing obvious that I did wrong. Don't carry this as something you missed.

On the hard part: it took four days for me to get a reply, and that was with a sixteen-year-old account, a public profile, and libraries that thousands of other projects depend on. I don't say that to discourage you, but so you know the silence is not a judgment on you or your case. Support looks badly overwhelmed right now, and the wait reflects that, not you. Keep your ticket open and add a short note to it every day or two to keep it active.

When you get back into the original account, and for anyone else reading who has been hit:

Do not open an affected repo in an AI editor (VS Code, Cursor, Claude, Gemini), and do not run npm install or npm test on it. That is how the payload runs. A no-checkout clone keeps it off your disk.
Reset each infected branch back to its parent commit, on every branch, not just the default one. These plants hide on side branches too, sometimes backdated and forged under your own name.
If you publish packages, check npm. In my case the published packages were never touched, only the GitHub source.
Reply here any time, and I will walk you through the cleanup personally. You are not alone in this, and you did nothing to deserve it.

[dmastag0]

Thank you for replying and I just finished reading your Part 2
I am so intrigued by this and hope that a Human will finally contact me to restore my access

[icflorescu]

a human will finally contact me to restore my access

I trust and hope that a human will contact you in a few days. It happened for me when I was starting to lose hope.

[dmastag]

Finally my account has been restored. Thanks for all the advice

[icflorescu]

@dmastag Glad to hear it!

[icflorescu]

If you were hit by this worm: a cleanup guide

I went through this on my own repositories and want to leave a complete, practical guide for anyone who lands here after being hit. It applies to the Miasma / Shai-Hulud-family worm that plants a .github/setup.js payload. Read the whole thing once before you start.

The full account of how this happened to me, and the forensics behind it, can be found here and here. This is just the practical fix.

These steps rewrite Git history and force-push. Understand each command before you run it, and keep the evidence backup from Step 3. I am sharing what worked for me, as is; adapt it to your situation.

Rule zero: never let an affected repo run

The payload executes when you open the repo in an AI-assisted editor (VS Code, Cursor, Claude, Gemini) or run npm install / npm test. So while cleaning up:

• Do not open the repo folder in any editor.
• Do not run npm install, npm test, or any script from it.
• Work from a clone that has no files checked out, so nothing can run.

Step 1: Clone with no checkout

git clone --no-checkout https://github.com/<you>/<repo>.git fix
cd fix
git fetch origin '+refs/heads/*:refs/remotes/origin/*'

Nothing lands on your disk as runnable files. This is safe.

Step 2: Detect by the payload file, not by author

The commits are disguised. On default branches they look like the github-actions bot. On side branches they are often forged under your own name and backdated to look like old, routine work. Do not trust the author. Check every branch for the payload file instead:

git for-each-ref --format='%(refname:short)' refs/remotes/origin | while read b; do
  git cat-file -e "$b:.github/setup.js" 2>/dev/null && echo "INFECTED: $b"
done

Every branch printed as INFECTED needs cleaning. Check all of them, not just main.

Step 3: Back up the evidence once

git clone --mirror https://github.com/<you>/<repo>.git evidence.git
tar czf evidence.tar.gz evidence.git

Keep this somewhere safe in case you need it later.

Step 4: Remove the malicious commit from each infected branch

For these attacks the malicious commit is usually the tip of the branch. Confirm it, then reset the branch back to that commit's parent:

# Confirm the latest commit on the branch is the one that added the payload:
git log -1 origin/<branch> -- .github/setup.js

# Reset the branch to the parent of the malicious commit (drops it from history):
git push --force-with-lease origin <MALICIOUS_SHA>^:refs/heads/<branch>

I chose reset over git revert on purpose: a revert leaves the 4.3 MB payload retrievable at the old commit, and for live malware you want it gone, not archived.

If a branch has legitimate commits on top of the malicious one, do not use the command above as-is, it would drop your real work too. You'll have to rebase just the bad commit out.

Step 5: Purge the copies you cannot see

Because of GitHub's fork network, a commit can stay reachable by its SHA even after it is off every branch. Removing it from your branches is not the definitive end. Open a support ticket, give them the full list of malicious commit SHAs, and ask them to garbage-collect and purge them through their sensitive-data removal process. That is the real kill.

Step 6 (the one people miss): rotate credentials properly

Cleaning the repos is pointless if the credential that let them in is still live. The attack is typically a harvested token, not your password, so 2FA does not stop it.

• The big one: revoke the OAuth app authorization, not just individual tokens. GitHub stacks many tokens under one authorization (for example the GitHub CLI). Revoking single tokens, re-logging-in, or reinstalling your machine does not close it. Go to Settings → Applications → Authorized OAuth Apps, and revoke any app you do not fully trust (the GitHub CLI included, then re-authorize fresh).
• If the GitHub UI errors out while you are revoking an app or token (the unicorn page), do not assume it worked. I cannot stress that enough. Come back when the platform is stable and confirm the app or token is actually gone. A revoke that failed behind an error page looks identical to one that succeeded, and the days when GitHub is straining are exactly the days you are most likely to be revoking something urgently.
• Rotate your npm tokens, and any cloud credentials (AWS, GCP, Azure) that ever sat on an affected machine.

A note that may reassure you

In my case the published npm packages were never touched. The attack was on the GitHub source repositories only. Check your own npm versions, but if you publish, your users may well have been safe the whole time.

If any of this is unclear, or your situation does not match these steps, comment here and I will try to help.

Ionut-Cristian Florescu