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?

[AbdulMoizJawed]

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

[MaheshTrapasiya]

Are you by any chance using copilot?

[Abhishek1350]

Are you by any chance using copilot?

Yes, but removed that access too, still no luck

[MaheshTrapasiya]

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.

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