Force Push Issue in repos

[waqas-0]

🏷️ Discussion Type

Bug

Body

Subject: Repeated unauthorized force-pushes injecting malware into my private repository

Hello,

My private repository waqas-0/Hyperzod has been force-pushed to by an unauthorized party three times in the past several days. Each time, every branch was reset to a single commit carrying obfuscated malicious JavaScript. I have cleaned the repository three times, and it has been re-compromised within roughly an hour on each occasion — so the credential being used is still valid.

What happens each time

All branches (main, feature/platform-admin-mobile-v2, fix/backend-port-and-supabase-wiring) are force-updated to one commit. That commit appends obfuscated JavaScript to exactly three files:

• apps/storefront-web/postcss.config.mjs
• apps/merchant-dashboard/postcss.config.mjs
• apps/platform-admin/postcss.config.mjs

These normally contain 81 bytes each. After each attack they contain roughly 30–33 KB.

Malicious commits

Attack | Commit SHA | Payload per file -- | -- | -- 1 | 64385e5c91e6b19092f6346266f86055cb6a0758 | 31,475 bytes 2 | 6d7aca74ca860770306ebe25499dc81695ce83d7 | 33,006 bytes 3 | ad451efd9378606c3f322f2da55872f22603a0f7 (main) and 8a8c982ed48ce386f2432270c567dcf32b94e593 (other branches) | 30,208 bytes

The payload differs in each attack, so it is being actively rebuilt rather than replayed.

Why this is urgent

postcss.config.mjs executes during every Next.js build. Any CI or hosting provider building this repository runs the attacker's code with the full build environment — including secrets — in scope. Static inspection of the payload (I have not executed it) shows createRequire, global.r = require, spawn, eval, process.env, and outbound calls to drpc.org and an …pc.io/eth endpoint, consistent with credential and cryptocurrency-wallet theft.

Impersonation

Each malicious commit is authored using my own account's email address, with a timestamp and commit message copied verbatim from a legitimate earlier commit of mine (760b518f78d6c8969e69a631ff1d07ea5da97b0c). In a deploy history the malicious commit is visually indistinguishable from the real one. I did not author these commits.

What I have already done

• Restored all branches from verified-clean local commits (three times)
• Confirmed my local clone was never compromised
• Disabled automatic deployment on my hosting providers
• Reviewed my authorized OAuth apps, GitHub Apps, deploy keys and personal access tokens

What I need from you

1. Identify the source. Please tell me which credential performed these force-pushes — token name or type, GitHub App, deploy key, or SSH key — with source IPs and timestamps. This is the only thing that will stop it; cleaning the repository clearly does not.
2. Purge the malicious objects. The commits above are no longer referenced by any branch, but remain retrievable by SHA. Please remove them permanently from storage.
3. Confirm my account is secure and flag any access grant I may have missed.

I have not attached the payload. I can provide the full contents of any affected file on request.

Thank you, waqas-0

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[muhammedtuerkmen]

Hi @waqas-0,

This is a critical supply-chain attack. Based on your payload analysis, here is why the re-compromise keeps happening and the exact steps to stop it immediately:

1. The Root Cause: "Build-Time Exfiltration Loop"

You noted that postcss.config.mjs executes during Next.js builds. The moment your CI/CD or hosting provider (Vercel, Netlify, Railway, GitHub Actions, etc.) attempted to build the repository after the first attack, the malicious script executed process.env and exfiltrated all environment variables and secrets stored in your build environment to drpc.org.

Even if you revoked your personal GitHub tokens, the attacker likely stole a Deployment Token, Vercel/Netlify Integration Secret, or Fine-Grained PAT stored inside your hosting platform's build secrets.

---

2. Immediate Action Steps to Lock Down the Repo

Step A: Stop Force-Pushes Immediately (Repository Ruleset)

Do not wait to find the token—block the vector right now:

1. Go to Repo Settings > Rulesets (or Branches).
2. Create a new ruleset targeting all branches (*).
3. Enable "Block force pushes" and "Restrict deletions".
   This will instantly block the attacker's script from overwriting your branches, even if they hold a valid token.

Step B: Nuke & Rotate ALL CI/CD Build Secrets

1. Go to your hosting provider(s) (Vercel/Netlify/GH Actions) and delete/rotate every single secret, API key, and environment variable.
2. Disconnect and re-authorize the GitHub integration on your hosting platform.

Step C: Check Hidden GitHub Access Points

Check these specific locations for leaked write-access:

• Deploy Keys: Go to Repo Settings > Deploy Keys (ensure no unauthorized key has write access).
• Fine-Grained PATs: Go to Account Settings > Developer Settings > Personal Access Tokens > Fine-grained tokens and revoke any token scoped to Hyperzod.
• SSH Keys: Check Account Settings > SSH and GPG keys for any unknown key.

---

3. Purging Objects & Getting Audit Logs (Official Support)

Please note that community members in GitHub Discussions cannot inspect private repo audit logs or purge orphaned Git objects.

1. Submit an Urgent Security Ticket: Go to GitHub Support Contact under Security/Account Access.
2. Provide the Commit SHAs: Give Support the exact commit SHAs (64385e5c..., 6d7aca74..., ad451efd...).
3. What Support can do:
   • Inspect internal access logs to tell you the exact Token ID / IP address used for those force-pushes.
   • Run a garbage collection (git gc) on GitHub's remote servers to permanently purge the dangling malicious commit objects.

Block force pushes first, rotate your build env secrets second! Hope this helps you eliminate the backdoor. If this guidance helps resolve the issue, please consider marking this as the accepted answer.

[stephane-courtioux]

Same campaign hit our organizations on Oct 11, 2026 (~05:19–05:24 UTC, two waves
3 minutes apart). All branches of every repo reachable by one member's account
were force-pushed; author name, email and commit messages were copied from the
original tip commit.

Indicators in our case:

• .vscode/tasks.json with "runOn": "folderOpen", hidden presentation, label
  "eslint-check", running node <path>/public/fonts/fa-solid-900.eot
• Fake Font Awesome files (fa-*.eot/svg/ttf/woff) dropped in a new
  public/fonts/ folder; fa-solid-900.eot is single-line obfuscated JS
• api.js files with benign code followed by whitespace-hidden obfuscated JS
• "dev" npm script changed to node api.js && vite
• .env with a base64 value decoding to a second-stage URL on files.catbox.moe
• .gitignore edited to stop ignoring .env and .vscode/

What worked for us:

• Remove/downgrade the compromised member FIRST, then restore (otherwise the
  token can re-push)
• Restore without cloning via the API: PATCH /repos/{owner}/{repo}/git/refs/heads/{branch}
  with the pre-attack SHA and force=true (old commits are still reachable by SHA)
• Branch protection with "Do not allow force pushes" + "enforce admins" blocked
  the attack on protected branches (requires a paid plan for private repos)
• Check every repo: /repos/{owner}/{repo}/activity?activity_type=force_push

Nobody on our side opened the infected checkouts, so the payload never ran
locally; the stolen credential most likely came from an earlier infection on
the member's machine.