URGENT: Targeted malware in our repositories altering tailwind.config.js and .gitignore via force-push. Has anyone seen this?

[rashed-kaysar-rasel]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Supply chain security

Discussion Details

Our engineering team is dealing with a highly suspicious supply chain/repository attack across all 3 of our GitHub organizations, and I am trying to figure out how they are maintaining persistence.

What we are seeing:
Several of our repositories suddenly showed as "updated 2 days ago." When we checked the commit history on the default branch, no files appeared to be changed on that date.

However, when we created a PR from the default branch to another branch, the diff revealed that two specific files were modified:

.gitignore: The attacker removed .env and added config.bat.
tailwind.config.js (and in some repos, vite.config.js): The attacker injected a massive block of obfuscated JavaScript at the very end of the file.

The injected code starts like this:

import { createRequire } from 'module';
const require = createRequire(import.meta.url);
global['!']='9-0191-4';var _$_1e42=(function(l,e){ ... })("rmcej%otb%",2857687);

The Problem:
We immediately identified this as malicious, revoked credentials, and force-pushed clean versions of the config files to remove the obfuscated code. However, we have been attacked twice. Even after cleaning the repository, the exact same malicious code was re-injected and pushed again today.

My Questions:

1. Has anyone faced this exact same malware variant? (Specifically the global['!'] payload and the config.bat file).
2. How do I find the root cause? Since cleaning the repo didn't work, I assume a developer's machine or our CI/CD pipeline is infected. How do we hunt down the specific machine or process doing this?
3. How can I prevent this permanently? What GitHub organization settings or local machine policies do we need to enforce to stop these phantom commits?

Any guidance on threat hunting this specific payload would be massively appreciated. We are currently treating all local .env secrets as compromised.

[Luke-Corwin]

The fact that the exact same payload reappeared after you force pushed clean files strongly suggests that the repository itself is not the root cause.

I would investigate in roughly this order:

1. Identify the actor that created the malicious commit.
   • Check the commit author.
   • Check the GitHub audit log.
   • Determine which account, token, GitHub App, or workflow performed the push.
2. Audit all write-capable credentials.
   • Personal Access Tokens (PATs)
   • GitHub App installations
   • Deploy keys
   • CI/CD secrets
   • Service accounts
3. Review GitHub Actions and external CI systems.
   • Look for workflows that have write permissions.
   • Check whether any workflow can commit back to the repository.
   • Verify recently added actions and third-party dependencies.
4. Inspect developer endpoints.
   • If the same code is being committed repeatedly, an infected workstation is a realistic possibility.
   • Review shell startup files, npm scripts, Git hooks, IDE extensions, and scheduled tasks.
   • Search endpoints for the unique strings appearing in the injected payload.
5. Enable additional protections.
   • Require pull requests before merging to protected branches.
   • Restrict direct pushes to default branches.
   • Require multiple reviewers.
   • Enable secret scanning and push protection.
   • Review organization audit logs regularly.

Regarding malware identification, the most reliable indicator is not the obfuscated code itself but the account or process creating the commit. If you can identify exactly which credential performed the push, you’ll often find the persistence mechanism much faster than by reverse engineering the payload first.

Since .env handling was modified, treating all previously exposed secrets as compromised and rotating them is the correct response.

[Sharon-rosario]

I have documented the Git Worm malware incident that halted our team for 2 days and infected 100+ repositories.
https://sharonrosario.space/case-studies/git-worm-malware-incident

The case study covers how it got in, how it spread, how it disguised itself, how it worked, and complete recovery steps—including cleaning PCs, VS Code, project configs, rotating secrets, and preventing future infections.

Everything we learned is documented here. Good luck.

[sohailahmad75]

Great summary from Luke-Corwin. I want to add the most likely root cause and
specific hunting steps.

---

The re-injection is almost certainly an npm postinstall script.

The most overlooked vector in attacks like this: a dependency in your
package.json (or a transitive dependency) has a malicious postinstall or prepare
lifecycle script that re-writes your config files every time npm install runs —
including in CI. This explains exactly why force-pushing clean files doesn't
stick.

Verify this first:

Find all postinstall/prepare scripts in your entire dependency tree

npm ls --json | grep -E "postinstall|prepare|preinstall"

Or more thoroughly:

find node_modules -name "package.json" -exec grep -l "postinstall|prepare" {} ;
| head -50

Look specifically for any recently-added or oddly-named packages. The payload
signature (global['!']='9-0191-4') is consistent with known npm supply chain
malware families that target build-tool config files precisely because they
execute in Node context on every build/install.

---

Why .gitignore was modified matters — it's not incidental.

Removing .env from .gitignore is the real goal. The attacker wants your .env file
accidentally committed and pushed in a future commit, exposing all your secrets
to the repository. The config.bat entry being added is likely a Windows-side
persistence dropper. If any developer runs npm install on Windows and a
config.bat lands on their machine, check scheduled tasks and startup entries
immediately.

---

Specific hunting checklist (in priority order):

1. Lock down your npm dependency tree right now
   npm audit
   npx better-npm-audit audit

Check for packages published or updated in the last 30 days that touch your

configs

2. Check git hooks on every developer machine
   ls -la .git/hooks/
   cat .git/hooks/post-checkout 2>/dev/null
   cat .git/hooks/pre-commit 2>/dev/null
   A malicious hook can re-inject the payload on every git checkout or git pull.

3. In GitHub: pull the exact audit log entry

Go to: Org Settings → Audit Log → filter by git.push around the attack
timestamps. This will show you the exact actor (user, PAT, GitHub App, or Actions
workflow) that performed the force-push. This is non-negotiable — without this,
you're hunting blind.

4. Check GitHub Apps installed on your org

Go to: Org Settings → GitHub Apps — look for anything with Contents: write
permission you don't recognize. A compromised OAuth app or GitHub App can push
silently without appearing in your commit author list.

5. Search all your Actions workflows for write permissions

Red flag: any workflow with this + a checkout step + a commit step

permissions:
contents: write

---

Permanent prevention (beyond what's already been suggested):

• Enable npm provenance and use --ignore-scripts in CI installs: npm ci
  --ignore-scripts — this blocks postinstall attacks entirely in your pipeline
• Pin all dependencies with an exact lockfile and verify package-lock.json
  integrity in CI
• Enable GitHub push protection + secret scanning on all orgs
• Use npm audit signatures (npm 9+) to verify package registry signatures
• Consider Socket.dev or Snyk for real-time supply chain monitoring

---

TL;DR for the original poster: Your cleanup isn't sticking because the injector
is likely still present — either as a malicious npm dependency running on
install, a git hook on a developer machine, or a GitHub App with write access.
The GitHub audit log will tell you the actor within minutes. Start there, then
run npm ci --ignore-scripts in all your CI pipelines immediately as a containment
measure.

[Sharon-rosario]

I have documented the Git Worm malware incident that halted our team for 2 days and infected 100+ repositories.
https://sharonrosario.space/case-studies/git-worm-malware-incident

The case study covers how it got in, how it spread, how it disguised itself, how it worked, and complete recovery steps—including cleaning PCs, VS Code, project configs, rotating secrets, and preventing future infections.

Everything we learned is documented here. Good luck.

[Pariola-droid]

We got hit by what looks like the same campaign and open-sourced a cleanup toolkit that may help others here: https://github.com/Pariola-droid/build-config-loader-cleanup

A few things that matched, plus some detail that might add to the picture:

Same IOCs: obfuscated loader appended to build configs (tailwind.config.js, postcss.config.*, next.config.*,
vite.config.js) and WordPress functions.php, hidden behind a long whitespace run. .gitignore edited to drop the .env ignores
and add config.bat. Entry line global['!']='...', marker _$_, an injected createRequire(...).

C2 via blockchain dead-drop (EtherHiding): the decoded payload resolves its C2 from attacker wallets via
hxxps://api[.]trongrid[.]io/v1/accounts/ (Tron), falling back to hxxps://fullnode[.]mainnet[.]aptoslabs[.]com/v1/accounts/
(Aptos), then pulls an XOR-encoded next stage over JSON-RPC and runs it with eval + a detached child_process.spawn (windowsHide).
~30s throttle.

Delivery: in our case an unsigned commit was force-pushed / amended into existing commits, with the git author spoofed to look
like the last legitimate committer. The actual pushing account (in the force-push event / audit log) is the compromised one — not
the spoofed author. Basically every branch was touched.

Re-injection: confirming what others noted: with a malicious postinstall/prepare, clean files don't stick. We use npm ci --ignore-scripts and audit lifecycle scripts.

Cleanup approach (in the toolkit): for every branch, restore each poisoned config file to its most recent clean version in
history (strips the appended loader without touching real work, which lives in other files), repair .gitignore, untrack committed
secrets, and commit a forward fix (no force-push, so it survives branch protection). Plus a read-only scanner over all branch tips +
full history + lifecycle scripts. And rotate every secret that was ever committed.

[plutack]

You need every member of your team that has access to rotate all credentials associated with github..
Eventually I had to format the whole system
Bit ideally you want to end all github sessions, this includes browser session. Revoke ssh keys, revoke gh cli credentials too if you have any
Basically any type of access that connects an host system to github or rather the git remote repo.
You can also start setting up branch rules ..protect deploy branch and also require committed have the commit signed or work with combination like this

[muhammad230]

We investigated this issue and it is not a GitHub platform bug. The behavior strongly indicates an active supply-chain compromise with persistent write access to our repositories.

The malicious changes being repeatedly re-injected (even after force-push cleanup) confirm that the attacker still controls at least one of the following:

A compromised developer machine with stored Git credentials or Git hooks
A compromised CI/CD pipeline (especially GitHub Actions or self-hosted runners)
A leaked GitHub Personal Access Token (PAT) or OAuth/GitHub App with repo write permissions

The modifications found are consistent with supply-chain malware targeting frontend build tools (e.g., vite.config.js / tailwind.config.js) and git configuration manipulation (.gitignore changes such as removing .env and adding config.bat). This pattern is commonly used to enable secret exfiltration and persistent execution during build or install steps.

Root cause investigation steps:
Audit GitHub organization Audit Logs to identify the exact identity pushing the commits.
Inspect all GitHub Actions workflows and disable them temporarily.
Check for self-hosted runners and assume compromise until verified clean.
Review all repositories for:
package.json scripts (postinstall/preinstall/prepare)
suspicious dependencies or lockfile changes
Audit all developer machines for:
Git hooks (/.git/hooks)
stored credentials (/.git-credentials, ~/.npmrc)
Rotate all secrets:
GitHub PATs
CI/CD secrets
cloud API keys
npm/yarn tokens
Immediate containment actions:
Temporarily disable CI/CD pipelines and GitHub Actions
Revoke all active tokens and sessions across the organization
Freeze repository write access where possible
Rebuild CI runners from a clean state
Treat all .env secrets as compromised and rotate them

This is not a one-time repository cleanup issue. Until the compromised identity or system is identified and removed, the attacker will continue to reintroduce the payload through legitimate write access.

[Sharon-rosario]

I have documented the Git Worm malware incident that halted our team for 2 days and infected 100+ repositories.
https://sharonrosario.space/case-studies/git-worm-malware-incident

The case study covers how it got in, how it spread, how it disguised itself, how it worked, and complete recovery steps—including cleaning PCs, VS Code, project configs, rotating secrets, and preventing future infections.

Everything we learned is documented here. Good luck.