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.

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

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[Z4YT0N]

Same campaign here, different variant tag — and I want to add one detail I have not seen written down anywhere, because it is the reason "we cleaned it and it came back" happens.

Variant: yours is global['!']='9-0191-4' with _$_1e42. Mine is global.i="A10-*19290" with a standard _0x-style obfuscator, and it resolves C2 from Ethereum wallet 0xa322E5f3D311D3080e6f0121063e9aDC2490Ef1a via 1rpc.io / eth.drpc.org / publicnode (the NullReceiver technique — the C2 IP is encoded in the recipient address of a zero-value transfer). No .gitignore change or config.bat in my case. Scope: 96 infected files across 65 branches, ~20 repos, five waves since 2026-08-09.

1. Why cleaning doesn't stick — the commit message lies

The commits that inject the loader carry messages like:

security: strip the injected loader from postcss.config.mjs

So the commit claiming to have removed the malware is the one carrying it. I "cleaned" this repeatedly and genuinely believed it was re-appearing on its own.

The tell is a twin commit pair:

92b788f6   committer date …T09:06:42Z   tree afdf604f   postcss.config.mjs =     99 bytes
4a119338   committer date …T09:06:43Z   tree 3e614a4a   postcss.config.mjs = 33,029 bytes

Same parent, same message, one second apart. The attacker takes your cleanup commit, rewrites it into an infected twin, and force-pushes the branch onto it. Check whether your "clean" HEAD has a twin — git log --all --format='%H %cI %s' and look for duplicate messages at adjacent timestamps.

2. Finding the source — the author name is forged, and that is provable

My local git config user.name is Fortune Code, so my real commits read Fortune Code <…>. The injected commits are authored by ‪Mahmoud‬‏ Amr — byte-for-byte identical to my GitHub profile display name, including the invisible directional marks (U+202A / U+202C / U+200F):

e2 80 aa  M a h m o u d  e2 80 ac  e2 80 8f  A m r

Local git cannot produce that; it only ever uses user.name. That string was pulled from the API by a script. So if the injected commits carry your profile display name rather than your configured git name, the commit was machine-generated off your machine — which redirects the hunt from "which laptop is infected" to "which credential still has write access".

Worth checking, since password rotation does not touch these:

• deployment-platform tokens (Vercel / Netlify / Railway) — those integrations hold a GitHub App installation with contents: write; reinstalling the App is what rotates it, revoking account tokens is not
• deploy keys, per-repo (mine: none)
• long-lived web sessions on those platforms
• ~/.netrc and .git-credentials — plaintext, first thing a stealer reads

3. Detection that works (the diff view will not help you)

The payload sits after ~280 spaces on the same line as export default config;, so it renders as a blank line in both the diff and the editor. Screen on size, then confirm on signature — and check every branch, not just the default:

gh api "repos/OWNER/REPO/contents/postcss.config.mjs?ref=BRANCH" --jq .size
# real config: 80-200 bytes.  infected: 30 KB+

Signatures worth grepping: global.i = / global['!'], eth_getTransactionByHash, global['r'] = require, and a run of 200+ spaces. Note a real tailwind.config.js is legitimately ~6.5 KB, so size alone will false-positive.

In my most recent wave, 8 repos were force-pushed in 4 minutes in alphabetical order — which is what convinced me it was scripted rather than a person.

Still unsolved, and I would take any pointer

Both audited machines are clean: full signature sweeps found zero infected files, no core.hooksPath / init.templateDir, no non-sample git hooks, no credentials on disk, no stray node -e processes, and no reflog or shell-history activity at the push times. The attack recurred after I rotated GitHub credentials and revoked every deployment token.

And on a free plan there is nothing I can do about it: no audit log to see which credential pushed, and both branch protection and rulesets 403 with "Upgrade to GitHub Pro" on private repos — so a force-push cannot be blocked at all. Detection is the only control available.

If anyone got past this and actually identified the persistence path after their machines came back clean, please post what it turned out to be.