Mysterious .bat files being force-pushed to all repositories - potential security concern

[aliziauddin]

Select Topic Area

Question

Body

Issue Summary

I'm experiencing a concerning issue where .bat (Windows batch) files are being force-pushed to multiple repositories in our organization. This has happened twice in the last 3 days.

Details

• Environment: I'm working on macOS exclusively
• Frequency: 2 incidents in 3 days
• Scope: Multiple repositories affected
• Push type: Force push (concerning as it overwrites history)
• My actions: I haven't manually created or committed any .bat files

What I've observed

• .bat files appearing across different repos
• These are force-pushed commits (not regular commits)
• I have not made these changes myself
• No one on my team uses Windows currently

Concerns

1. This could indicate a compromised account or token
2. Force pushes suggest something is overwriting git history
3. The widespread nature across repos is unusual

Questions

• Has anyone else experienced automated force pushes like this?
• Could this be caused by a GitHub App, Action, or integration?
• What's the best way to audit what/who is making these commits?
• Should I rotate all access tokens and deploy keys as a precaution?

Any guidance would be greatly appreciated. This feels like a potential security issue.

[bhashas]

This is a classic signature of a Supply Chain Attack or a Token Leak. The fact that you see .bat files while being on macOS suggests that an automated bot is targeting your CI/CD environment or using a compromised Windows machine to push code.

Here is a checklist to help you identify and stop the breach:

1. Identify the Source (The "Who")

Go to your Organization Settings > Compliance > Audit Log.

Search for the push events. Check the IP address and the Actor.

Look for the auth_method. Was it a Personal Access Token, a GitHub App, or an SSH Key?

2. Immediate Containment (The "Stop")

Revoke all PATs: If you use Personal Access Tokens, revoke them immediately.

Check GitHub Apps: Go to Settings > GitHub Apps and Installed GitHub Apps. Revoke any suspicious third-party integration you don't recognize.

Branch Protection: Enable "Lock branch" or "Restrict pushes" on your main branches. Disable "Allow force pushes" in your Branch Protection Rules. This is your best defense against history rewriting.

3. Investigation (The "Why .bat?")

Inspect the content of a .bat file. Does it contain a PowerShell script, an IP address, or an attempt to download a payload (e.g., curl or certutil)?

Often, these scripts are designed to steal environment variables (Secrets) from your CI/CD runners (GitHub Actions).

4. Clean Up

Since the history was force-pushed, you might need to use git reflog on a clean local machine to recover your previous state and force-push the "clean" version back.

Stay safe, and don't hesitate to contact GitHub Support directly if you suspect a platform-level compromise of your account.

[bhashas]

This behavior is a major red flag for a Supply Chain Attack. The forced pushes and the appearance of .bat files suggest that an automated bot has likely compromised one of your Personal Access Tokens (PAT) or Static Credentials (like AWS Access Keys) stored in your GitHub Secrets.

While rotating keys is the first step, the long-term architectural solution to prevent this is implementing OIDC (OpenID Connect).

Why OIDC is the answer to your problem:
Zero Static Secrets: With OIDC, you no longer store long-lived AWS_SECRET_ACCESS_KEY or similar credentials in GitHub. There is nothing for a malicious .bat file to "steal" and send to an external server.

Short-Lived Tokens: GitHub Actions exchanges a temporary JWT (JSON Web Token) for short-lived cloud credentials that expire automatically.

Identity-Based Access: You can configure your Cloud provider (AWS/Azure/GCP) to only trust requests coming from your specific GitHub Organization, Repository, and even a specific Branch.

Immediate Action Plan:
Audit the Actor: Check your Organization Audit Logs to see which token or user performed the force-push.

Enable Branch Protection: Immediately toggle "Block force push" and "Require Pull Request" on your main branches. This would have physically blocked the bot from overwriting your history.

Switch to OIDC: Replace your static secrets with a Cloud Identity Provider (IdP) trust relationship.

By moving to OIDC, you eliminate the root cause: the existence of permanent, exfiltratable credentials in your environment.

Stay safe!

[thisistanishq]

This is a legitimate security concern, and you’re right to treat it seriously — especially because these are force pushes across multiple repos.

Here’s how to think about it and what to do immediately.

---

What this almost certainly is (and isn’t)

Since:

• You’re on macOS only
• No one on your team uses Windows
• .bat files appeared in multiple repositories
• The changes were force-pushed
• You did not create or commit them

This is not a local git issue and not accidental user behavior.

The most common causes in cases like this are:

• A compromised Personal Access Token (PAT)
• A GitHub App or Action with write + force permissions
• A CI/CD bot or automation misconfigured (or compromised)
• Less commonly, a compromised machine running unattended automation

---

Step 1: Identify who made the force pushes (critical)

For one affected repo, run:

git log --show-signature --oneline --decorate

Then check on GitHub:

• Commit author
• Commit committer
• Whether it says “via GitHub App”
• Whether the email is a bot, noreply, or unfamiliar

This will usually tell you immediately whether this was:

• A user token
• A GitHub App
• GitHub Actions

---

Step 2: Audit org-level integrations (very common culprit)

In Organization Settings:

• Installed GitHub Apps
• Actions → Runners
• Actions → Secrets
• Deploy Keys

Look for:

• Apps with Contents: write
• Apps allowed to bypass branch protections
• Any automation with force push capability

If you see an app you don’t fully recognize → disable it immediately.

---

Step 3: Rotate credentials NOW (don’t wait)

Even if you’re not 100% sure yet, rotate as a precaution:

• Revoke all Personal Access Tokens
• Rotate Deploy Keys
• Rotate GitHub Actions secrets
• Re-authenticate local git credentials

This is standard incident response, not overreacting.

---

Step 4: Lock this down so it can’t happen again

Enable / verify branch protection rules:

• Disable force pushes on default branches
• Require PRs
• Require signed commits (highly recommended)
• Restrict who can push to protected branches

This turns a scary incident into a contained one.

---

Step 5: Check GitHub security logs

In Organization → Security → Audit Log, filter by:

• force_push
• repo.push
• actor
• oauth_app
• github_app

This will show exactly what actor performed the pushes and when.

---

Important note about .bat files

The file type itself is likely incidental, not the root problem.
Attackers and misconfigured automation often drop small files to test write access across repos.

The force push + multi-repo scope is the real red flag.

---

TL;DR

• This is not normal
• This is very likely automation or token-based
• Rotate credentials immediately
• Audit GitHub Apps / Actions
• Enable strict branch protections
• Use the audit log to identify the actor

You’re asking the right questions — treat this like a mild security incident and you’ll be fine.

If you find the audit log actor and want a second opinion on it, happy to help interpret it.

[aliziauddin]

The problem was that its a force push in the last pushed commit under my name

[thisistanishq]

That actually helps clarify things a lot.

Seeing the force-push under your name doesn’t automatically mean it came from your laptop. GitHub will show your name if any token, app, or automation linked to your account made the push.

Very common causes:

• An old personal access token used by a script or CI
• A GitHub Action / App acting on your behalf
• Cached credentials somewhere you forgot about

What I’d do next (simple and safe):

1. Open one of those commits on GitHub and check:

   • Author vs committer
   • Whether it says “via GitHub App”
   • The commit email (bot / noreply / yours)

2. Rotate credentials anyway (good hygiene):

   • Revoke old PATs
   • Review installed GitHub Apps
   • Rotate Actions secrets

3. Add branch protection to block force-pushes going forward.

Also, the .bat files themselves probably aren’t the real issue — they’re likely just output from whatever automation did the push. The important signal here is the force-push across multiple repos.

Once you find which token or app did it, this usually becomes very straightforward to fix.

[bhashas]

If the commits appear under your name and are being force-pushed, this confirms that your credentials (PAT or SSH Key) have been stolen. The attacker is using your identity to bypass suspicion.

1. Immediate "Burn" Strategy:

Delete your current PAT: Go to Settings > Developer Settings > Personal Access Tokens and revoke every single one.

Check your SSH Keys: Check Settings > SSH and GPG keys. If there is a key you don't recognize, delete it immediately.

Rotate your local Git credentials: On your Mac, clear your Keychain (search for "github.com") to ensure no compromised credentials remain locally.

2. Why OIDC is the fix: By switching to OIDC (OpenID Connect) for your deployments, you stop using these long-lived tokens that can be stolen. OIDC uses a trust relationship between GitHub and your Cloud provider, meaning no password or token is ever stored in a way that an attacker can "force-push" with it later.

3. Recovering your history: To fix your repo, you need to find the "real" last commit hash before the force-push. You can find it in your local git reflog. Then, you will need to:

git reset --hard

Protect the branch (Settings > Branches) to Disable Force Push so this cannot happen again while you clean up.

This is a serious "Impersonation Attack". Stay vigilant.

Ce que ça signifie pour toi (Leçon apprise)
C'est l'exemple parfait de pourquoi on ne doit JAMAIS :

Laisser le "Force Push" autorisé sur la branche main.

Utiliser des clés statiques quand on peut utiliser de l'OIDC.

L'attaquant a probablement trouvé son jeton GitHub (PAT) parce qu'il l'avait peut-être laissé traîner dans un script, ou sur son ordinateur.

[bhashas]

since the attacker is impersonating you to push files across multiple repos, they are likely hunting for Cloud Secrets (AWS/Azure) stored in your environment variables.

Beyond rotating your PAT, check if any of your repositories have 'Secrets' defined in Actions. If they do, consider them compromised and rotate your Cloud Access Keys immediately. Moving forward, I highly recommend using OIDC to eliminate static secrets and GPG signing for your commits so GitHub can verify that it's actually you sitting behind the keyboard

[thisistanishq]

I want to clarify this with concrete fixes rather than speculation, because there are very clear ways to stop this completely — regardless of whether the cause is automation or a leaked credential.

Here are the hard stops that actually prevent this from ever happening again:

1) Disable force-pushes at the org / repo level

Enable branch protection on all default branches:

• Disable force pushes
• Require PRs
• Restrict who can push

Once this is on, no token, app, or attacker can rewrite history, period.

---

2) Identify the exact actor via the audit log (this is definitive)

In Org → Security → Audit Log, filter by:

• force_push
• actor
• oauth_app
• github_app

This tells you exactly whether it was:

• a PAT
• GitHub Actions
• a GitHub App
• a user session

No guessing needed — GitHub records this explicitly.

---

3) Remove long-lived credentials entirely

Instead of just rotating tokens:

• Delete unused PATs
• Remove deploy keys
• Limit GitHub Apps to read-only unless required

If CI/CD is needed, use OIDC so there are no stored secrets to steal.

---

4) Require signed commits

Enable required commit signing.
This guarantees that future commits can only come from a verified key, not “someone pretending to be you”.

---

5) Verify whether this is compromise or automation

If this were an active attacker:

• You’d usually see new SSH keys
• Login alerts
• Permission changes
• API abuse beyond just .bat files

If none of those exist, the probability strongly favors misconfigured automation, not impersonation.

---

Bottom line

This can be fully mitigated today with branch protections + audit logs + credential cleanup.

At that point, even if a token were leaked, it simply wouldn’t be able to do damage.

That’s why I’m focusing on prevention and verification rather than jumping straight to worst-case assumptions.

[devpeachy]

We got the same issue. If you have configuration files such as vite.config.js, postcss.config.js, etc., you may also find an additional script that starts with global['!'] =. Isn’t it interesting that all these PATs were leaked at the same time?

[MJ16MJ]

I am facing same issues in almost all my private repositories, I have removed extra PATs changed my password but still facing these issues.

Have anyone found the solution yet ?

[RAQEEB212]

remove all the PATs, some of previously used PATs might be compromised, also the IDE is compromised,

that .bat file is creating the .vscode autonomous task which will run on every operating system ,

[saad7677]

@aliziauddin
Are you able to find the solution because same issue is happeining with me

[Abhishek1350]

I would suggest disabling it completely from vs code and github.

Also can you check if there is any unwanted file in .vscode folder in C DRIVE.

I removed copilot extension like a month ago, and also did complete system reset. I think there's something else going on,

[saad3781]

@AbdulMoizJawed go to github settings and disable copilot completley there is a repo access option for copilot diable that.

[Abhishek1350]

@AbdulMoizJawed go to github settings and disable copilot completley there is a repo access option for copilot diable that.

Are you sure copilot is putting malicious code on our repos?

[saad3781]

yes i agree with @MaheshTrapasiya

[aliziauddin]

No solution yet. I just revoked all my accesses and rotate everything; now it's working fine
I would suggest that for the time being you make a practice of looking for .bat files, or any script added in the code starting from global
If you have a Mac or Linux, run this command ps aux | grep "node -e global" | grep -v grep to check if anything malicious is running or not.

[geniusmonir]

We are facing same issues here. Even with one of our org member, reset the computer removes all PATs, cleaned everything, yet it keep force pushing! I think GH copilot is doing something weired here!

[aliziauddin]

No solution yet. I just revoked all my accesses and rotate everything; now it's working fine
I would suggest that for the time being you make a practice of looking for .bat files, or any script added in the code starting from global
If you have a Mac or Linux, run this command ps aux | grep "node -e global" | grep -v grep to check if anything malicious is running or not.

[saadurrehman]

@geniusmonir after removing github copilot, whats the response ? i feel you were right about github copilot.

[geniusmonir]

@saadurrehman We enabled the ESET Endpoint solution for all engineers in the company. After the first wave, we were hit by second and third waves originating from different engineers’ accounts.
As a result, we re-imaged all machines, revoked all SSH keys, PATs, and PGP keys, and cleaned up all repositories and pull requests. Everything is now secure and stable.
In total, we experienced three waves of malware attacks

[geniusmonir]

@saadurrehman it was not related to copilot actually, It spreading when you are building project and the code executed on your machine it steals all ssh keys PATs

[kartikvermajs]

This is not expected GitHub behavior and does sound like a potential security issue rather than a normal Git operation.

Force pushes across multiple repositories, especially with files you didn’t create, usually indicate that something with write access is acting automatically — for example:

A compromised Personal Access Token (PAT)

A GitHub App or integration with write permissions

A GitHub Action workflow making automated commits

Less commonly, a compromised local environment

A few things I’d recommend checking:

Review commit authors (git log) to see what identity is being used

Check your organization’s audit logs for force push events

Review installed GitHub Apps and remove anything unfamiliar

Inspect .github/workflows for any automation that could be committing

Verify whether any tokens or credentials may have been exposed

Given that force pushes are involved and affecting multiple repos, I’d treat this as a potential credential compromise and rotate tokens/keys as a precaution.

If you can share the commit author/email or a sample commit, it would help narrow down the source.

[naqvi110k]

This looks like a compromised token or GitHub App — here's what to do immediately:

1. Audit who made the pushes

Go to your org → Settings → Audit Log
Filter by git.push events
Check which user/app/token made the force pushes

2. Check connected apps and tokens

github.com/settings/tokens — revoke anything suspicious
github.com/settings/installations — remove unknown GitHub Apps
Check org-level apps: Organization → Settings → GitHub Apps

3. Rotate credentials immediately

Revoke all personal access tokens and create new ones
Rotate any deploy keys across affected repos
Revoke and regenerate OAuth tokens

4. Check your Actions workflows

Look for any workflow that runs on a schedule and has write access
A misconfigured Action can auto-commit files unintentionally

5. Enable branch protection

Block force pushes on all repos: Settings → Branches → Require pull request
This prevents history overwriting going forward

Most likely cause: A GitHub App or Action with write access is generating .bat files automatically — possibly a dependency tool or CI script misconfiguration.
Yes, rotate all tokens as a precaution — better safe than sorry.

[saadurrehman]

but how it was executing when your machine was offline *Muhammad Saad ur rehman* Senior Software Engineer +923228540429 | ***@***.*** Linkedin <https://www.linkedin.com/in/muhammad-saad-ur-rehman-736683160/> | Github <https://github.com/saadurrehman>

…

On Thu, 2 Apr 2026 at 11:00 PM, Md Moniruzzaman ***@***.***> wrote: @saadurrehman <https://github.com/saadurrehman> it was not related to copilot actually, It spreading when you are building project and the code executed on your machine it steals all ssh keys PATs — Reply to this email directly, view it on GitHub <#185880?email_source=notifications&email_token=AG2Y7QQAJGOS6PRYSOOITPD4T2TFBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRUGI3DSOJQUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16426990>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AG2Y7QVQ7IBS2LTQUG6QK734T2TFBAVCNFSM6AAAAACTIWEEQSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBSGY4TSMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[geniusmonir]

@saadurrehman So basically what I understand so far, it pulls the access keys and store them to their server i have seen an IP inside the malware where they are sending POST request. Then they use those keys to execute the operation. If you keep your keys like that they can use it to act like you.

[Siddh4194]

I have been experienced the same issue with the github repository.

I have created one article which explains what worked for us https://www.linkedin.com/pulse/signed-commits-missing-security-layer-github-pipelines-siddhant-kadam-48src/. Please take a look and let me know if anything is unclear.

[6mile]

Heya everyone, I'm sorry to say, if this has happened to you, you have been a victim of North Korean hackers. They compromise your machine through fake interviews, coding challenges, or by having you download other people's GitHub repositories and then open the source code in VSCode. You can read about it here: https://opensourcemalware.com/blog/polinrider-attack

[mehediScriptDev]

possible... first my office orgs hit by someone elses fault..but my own repo hit my own fault ..."fake interviews, coding challenges" i fall for that.. but how can they do it? just google meet and coding challenges?

[6mile-puppet]

Its in the source code. look for .vscode/tasks.json files and when you git clone that repo down to your machine, and then you open it in VSCode it runs the payload which starts the infection. There are alternate infection vectors like NPM or PyPI packages, but the VSCode vectors is the most common.

[mehediScriptDev]

man!! same thing happend to me.. in my office i work with windows and in home i use mac ... first day it was a sales member whos github account used to force push.. We thought maybe he did this, but at the same time without anything just that config.bat file and remove env from .gitignore..

then we found this , https://github.com/OpenSourceMalware/PolinRider

two days later i saw my own force push on my private repo (my account)...main branch wasnt secure so force push worked perfectly and my old code gone, i dont even have those code in local machine..

now when i create repo i secure all branches first....

the interesting thing is, it happend when i was offline..same for our sales team member... not my all repo ..so its possible its related to some vulnerable npm packages ...

[meShuaibKhalid]

Same thing happening to me and every second perosn in our organization, though i removed all PAT and the only way to push code from my machine is by ssh password, it is still force pushing by my name

[Siddh4194]

I have been experienced the same issue with the github repository.

I have created one article which explains what worked for us https://www.linkedin.com/pulse/signed-commits-missing-security-layer-github-pipelines-siddhant-kadam-48src/. Please take a look and let me know if anything is unclear.

[Zeeshan-AlphaHive]

Hi Zeeshan here  What i did was went to developer settings and revoked the apps access including render lovable or other deployment platform and it's been more than 1 month since last force pushes and also add a force push restrictions on repos On Sat, Aug 29, 2026, 01:38 pm Muhammad Shuaib Khalid ***@***.***> wrote: Same thing happening to me and every second perosn in our organization, though i removed all PAT and the only way to push code from my machine is by ssh password, it is still force pushing by my name —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#185880?email_source=notifications\u0026email_token=BVL4TELTHV2RWRVHWFIEWJT5MKJBDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHE3DQOBVUZZGKYLTN5XKM3LBNZ2WC3FFMV3GK3TUVNTW2YLJNRPWG3DJMNVQ#discussioncomment-18196885", "url": "#185880?email_source=notifications\u0026email_token=BVL4TELTHV2RWRVHWFIEWJT5MKJBDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHE3DQOBVUZZGKYLTN5XKM3LBNZ2WC3FFMV3GK3TUVNTW2YLJNRPWG3DJMNVQ#discussioncomment-18196885", "name": "View Discussion" }, "description": "View this Discussion on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[Zeeshan-AlphaHive]

Now even if you clear you laptop still the force pushes will be made because its due to third party apps in GitHub which have access to your GitHub  On Sat, Aug 29, 2026, 01:40 pm Muhammad Zeeshan Zia ***@***.***> wrote: Hi Zeeshan here  What i did was went to developer settings and revoked the apps access including render lovable or other deployment platform and it's been more than 1 month since last force pushes and also add a force push restrictions on repos On Sat, Aug 29, 2026, 01:38 pm Muhammad Shuaib Khalid ***@***.***> wrote: Same thing happening to me and every second perosn in our organization, though i removed all PAT and the only way to push code from my machine is by ssh password, it is still force pushing by my name —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#185880?email_source=notifications\u0026email_token=BVL4TELTHV2RWRVHWFIEWJT5MKJBDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHE3DQOBVUZZGKYLTN5XKM3LBNZ2WC3FFMV3GK3TUVNTW2YLJNRPWG3DJMNVQ#discussioncomment-18196885", "url": "#185880?email_source=notifications\u0026email_token=BVL4TELTHV2RWRVHWFIEWJT5MKJBDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHE3DQOBVUZZGKYLTN5XKM3LBNZ2WC3FFMV3GK3TUVNTW2YLJNRPWG3DJMNVQ#discussioncomment-18196885", "name": "View Discussion" }, "description": "View this Discussion on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[meShuaibKhalid]

Thanks for this helpful insight, then I suspect Codex ChatGPT and Vercel.
I've removed both

[Zeeshan-AlphaHive]

Also make sure to go to settings/integrations/applications and inside that revoke installed GitHub apps , authorised GitHub apps and oAuth apps + In your local repos  If you turn on the window defender it will give warning and auto delete sub files , so you if copy the contents of that file in a notepad you will see malicious script So you need to filter that On Sat, Aug 29, 2026, 01:47 pm Muhammad Shuaib Khalid ***@***.***> wrote: Thanks for this helpful insight, then I suspect Codex ChatGPT and Vercel. I've removed both —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#185880?email_source=notifications\u0026email_token=BVL4TELGLXVTGTPL2VN5AML5MKKDNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHE3DSOJSUZZGKYLTN5XKM3LBNZ2WC3FFMV3GK3TUVNTW2YLJNRPWG3DJMNVQ#discussioncomment-18196992", "url": "#185880?email_source=notifications\u0026email_token=BVL4TELGLXVTGTPL2VN5AML5MKKDNA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHE3DSOJSUZZGKYLTN5XKM3LBNZ2WC3FFMV3GK3TUVNTW2YLJNRPWG3DJMNVQ#discussioncomment-18196992", "name": "View Discussion" }, "description": "View this Discussion on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[19e11]

A good first step would be to check the affected commits and audit logs to identify exactly which account, token, GitHub App, or workflow performed the force push.

I’d also check the repository’s Actions/workflow history and organization audit log around the timestamps of the incidents. If the actor is an unexpected user or integration, I’d revoke/rotate the relevant credentials immediately and review repository permissions.

Since this is happening across multiple repositories, checking organization-level integrations and GitHub Apps would probably be especially important.

[theravikumar077]

One additional thing I’d check is whether the force-pushes correlate with a scheduled GitHub Actions workflow. Reviewing the workflow run logs and the actor associated with each run should help narrow down whether this is coming from automation rather than a local Git client.

[NLZoro]

Another thing worth checking is the organization audit log and GitHub Apps/integrations around the exact timestamps. I’d also review branch rules, Actions secrets, and any PATs/deploy keys with write access across the affected repos. If the same actor or credential shows up across them, that could help pinpoint the source.

[Zeeshan-AlphaHive]

The issue is contagious! About 1 week before the force pushes were made from my GitHub account, the force pushes were from other developer name so everyone ignored it So when i got infected then we got to know about what was happening and all code was being replaced eith main branch Also my 2 accounts are infected ( personal and work account) and all the force pushes are made from both accounts at a same time with a delay of 2 sec for each repo . I removed everything from local machines but still the pushes were made  On Sat, Aug 29, 2026, 02:00 pm Ravi Kumar ***@***.***> wrote: One additional thing I’d check is whether the force-pushes correlate with a scheduled GitHub Actions workflow. Reviewing the workflow run logs and the actor associated with each run should help narrow down whether this is coming from automation rather than a local Git client. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#185880?email_source=notifications\u0026email_token=BVL4TENTL7DKELRCNJEDTD35MKLTJA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHE3TANJUUZZGKYLTN5XKM3LBNZ2WC3FFMV3GK3TUVNTW2YLJNRPWG3DJMNVQ#discussioncomment-18197054", "url": "#185880?email_source=notifications\u0026email_token=BVL4TENTL7DKELRCNJEDTD35MKLTJA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHE3TANJUUZZGKYLTN5XKM3LBNZ2WC3FFMV3GK3TUVNTW2YLJNRPWG3DJMNVQ#discussioncomment-18197054", "name": "View Discussion" }, "description": "View this Discussion on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[6mile]

A new way that threat actors are staying persistent on local machines is by overwriting your npm CLI file. This is from the OpenSourceMalware PolinRider Incident Response guide: https://opensourcemalware.com/blog/developer-guide-getting-over-polinrider

"On several infected machines, npm/lib/cli.js (normally a few hundred bytes and four lines) had been overwritten with a malicious version of the npm CLI that's designed to maintain persistence. The malicious npm CLI is ~1 MB, with the payload appended after a long run of whitespace starting on line 5. This one matters more than a poisoned config file, because it means every npm, npx, or npm exec call re-spawns the malware, and it survives a reboot, since it's living in the tool you use to start anything else, not in a process that dies when the machine restarts. One developer traced their reinfection to an editor or extension silently running npm exec @latest in the background. You'll have to uninstall npm and node, make sure everything is killed, then you can reinstall and confirm the size is correct (compare npm/lib/cli.js against a known-good copy, or check its size and first several lines directly"

[kevalpatelck]

We made an open-source tool and extension called Code Guardian (GitHub Source) specifically designed to solve and prevent this exact attack vector.

---

How This Attack Works:

1. Force-Push Propagation: Attackers use scripts that backdate timestamps, amend commits (git commit --amend), bypass local validation (--no-verify), and force-push (git push --force) to stealthily insert payloads without normal review.
2. Folder-Open Execution: They often inject tasks into .vscode/tasks.json with "runOn": "folderOpen" and "reveal": "never". When another developer pulls the branch or opens the repository, the malicious task executes immediately in the background without manual confirmation.
3. Disguised Payloads: Payloads are often concealed as fake font assets (e.g. executable JavaScript inside .woff2 files) or injected directly into framework config files (postcss.config.js, next.config.js).

---

How to Protect Your Local & Team Environment:

1. Use Pre-Push & Pre-Commit Protection Hooks:
   Block commits and pushes containing --no-verify scripts, stealth .vscode configs, and disguised binaries before they reach your remote repository.

2. Disable Automatic Task Execution in VS Code:
   Add this to your settings.json:

   "task.allowAutomaticTasks": "off"
   

[19e11]

This is a useful perspective, especially the point about tasks.json and automatic task execution. One clarification, though: --no-verify only bypasses local Git hooks; it doesn't by itself bypass GitHub-side branch protection or other server-side controls.

I'd also prioritize identifying the actor behind the force-push through the organization audit log before assuming the .bat files are part of a supply-chain attack. Once the actor/authentication method is known, it becomes much easier to determine whether the source was a compromised credential, GitHub App, Actions workflow, or another integration.

For repositories where automatic tasks aren't required, disabling automatic task execution and reviewing .vscode configuration is definitely a good additional layer of defense.

[kevalpatelck]

Completely agree — that's a very important clarification.

--no-verify only bypasses local Git client hooks, so server-side branch protections (disallowing force-pushes, requiring PR reviews and signed commits) remain the primary hard barrier against unauthorized pushes.

Checking the organization audit logs is also crucial, as force-pushes in these scenarios almost always stem from compromised developer Personal Access Tokens (PATs), leaked SSH keys, or rogue CI/CD workflows.

The local hooks and task interceptor are designed as a defense-in-depth layer to prevent developer machines from immediately executing malware when checking out untrusted feature branches, forks, or PRs where branch protections might not apply. Thank you for adding that context!

[19e11]

Exactly, that distinction between server-side controls and local defense-in-depth is important.

I especially like the point about untrusted PRs and feature branches, since local protections can still be valuable even when the remote repository has strong branch protection.

One additional safeguard could be running a repository security scan in CI that checks for suspicious .vscode configurations, unexpected executable files, and modifications to workflow/configuration files before allowing a merge. That would provide another layer between the code entering the repository and reaching a developer's machine.