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.

[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.