Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Recover a compromised GitHub repository in this order: preserve evidence, contain access and execution, determine the scope, revoke or rotate every possibly exposed credential, then choose between restoring trusted refs and rewriting history. Rewriting is not the default. It is justified when secrets or sensitive files must be removed from every relevant ref, and it changes commit IDs, invalidates signatures and requires coordinated cleanup of clones, forks and pull requests.
What recovery is—and what it is not
A clean-looking default branch does not prove that the attacker has been removed. A compromise can include stolen personal access tokens, changed workflow files, malicious self-hosted runners, webhooks, deploy keys, installed apps, altered branch protections, or credentials that let an attacker reach a cloud or package registry. Repository recovery therefore has two separate goals:
- Account and system recovery: stop unauthorized access, remove persistence, repair the cause and restore trusted development and deployment.
- History cleanup: remove a secret or sensitive file from Git objects and all relevant references when leaving it in history creates an unacceptable exposure.
Rotating a credential can make it unusable without changing any commit hash. A history rewrite cannot undo a credential that was already copied, so revoke or rotate first. GitHub describes the recovery objective as removing traces of compromise, fixing the root cause and restoring systems to a secure state.
Before touching the repository: preserve evidence
Do not start by deleting the suspicious branch or force-pushing a replacement. Destructive cleanup can remove the information needed to understand the incident, prove what happened or identify other affected systems.
#1 Best Overall
- Easily store and access 2TB to content on the go with the Seagate Portable Drive, a USB external hard drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Capture the state that may disappear
- Audit-log events, including sign-ins, token use, permission changes and repository visibility changes.
- Workflow runs, job logs, artifacts and changes to workflow files.
- Suspicious commits, branches, tags, pull requests and force-push events.
- Branch-protection and required-review changes.
- Webhooks, deploy keys, GitHub Apps, personal access tokens, environment settings and organization or repository access changes.
- Self-hosted runner registrations, labels, logs and machine details.
- Release assets, package publications and any references to external cloud or deployment systems.
Keep an untouched evidence copy separate from the working recovery copy. Record UTC timestamps, actor identities, affected refs, commit hashes, URLs or identifiers for relevant events, and the person who collected each item. Preserve screenshots or exports when an interface does not provide a durable download.
Opening a support ticket does not preserve logs or extend their retention period. Treat collection as an incident-response action, not as something support will do later.
Contain access and execution without creating new damage
Use the least disruptive controls that stop the observed attack. If an attacker is actively running code or using credentials, availability may be less important than stopping execution; if the activity is historical, preserve more evidence before making changes.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Stop malicious code from running
- Cancel suspicious workflow runs and disable GitHub Actions temporarily when necessary.
- Remove or isolate self-hosted runners that you do not fully trust. A runner can contain credentials, cached source and persistence outside the repository.
- Disable suspicious webhooks and inspect their destinations and delivery history.
- Delete branches that contain malicious code or workflows when their removal is justified and the evidence copy is complete.
Block unauthorized access
- Revoke known-compromised tokens and sessions immediately.
- Review repository and organization members, teams, outside collaborators and SSO authorizations where applicable.
- Inspect deploy keys, GitHub Apps, personal access tokens, environment approvals and workflow permissions.
- Remove unauthorized users, apps, keys, runners and webhooks rather than merely hiding their changes.
Containment is not a substitute for rotation. An attacker may have copied a credential before you disabled the visible access path.
Scope what the attacker could change or reach
Establish a last-known-good point and compare it with every current reference. Do not limit the review to the default branch: a malicious tag, release asset or workflow can be used even when the default branch looks normal.
Review Git references and code changes
- Compare branches and tags with the last trusted refs.
- Inspect recent commits, merge commits, force-pushes and changes to workflow files.
- Review pull requests, comments, review decisions and branch-protection changes.
- Check release assets, package publications and generated artifacts for unexpected content.
Review GitHub control planes
- Audit-log events for account, organization and repository changes.
- Workflow logs and artifacts, including accidental secret disclosure in output.
- Self-hosted runners and the machines on which they execute.
- Webhooks, deploy keys, installed apps, collaborator and team membership, and repository visibility.
Trace external reach
List every secret available to affected workflows, environments or applications. Determine whether an attacker could have reached cloud accounts, deployment targets, package registries, signing systems, databases or other repositories. A malicious workflow can use a legitimate secret without changing application code, so the absence of an obviously malicious commit is not proof that external systems are safe.
Preserve logs and artifacts before deleting them. Record whether each item was merely exposed, demonstrably used, or still uncertain; the uncertainty itself belongs in the incident record.
Rank #2
- Easily store and access 5TB of content on the go with the Seagate portable drive, a USB external hard Drive
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
Rotate every credential that may have been exposed
Assume a credential may be usable if it appeared in source, a workflow log, an artifact, a clone, a fork or a pull request. Revoke or rotate first, then clean the history. GitHub specifically notes that when the issue is a secret, rotation may be sufficient and a rewrite can add unnecessary risk.
| Credential or access path | Recovery action | Why it matters |
|---|---|---|
| Personal access tokens and sessions | Revoke tokens and terminate or reauthorize sessions as appropriate. | They may provide direct repository or organization access even after a commit is removed. |
| Repository and environment secrets | Replace values, update consumers and invalidate the old values. | Workflow history, artifacts and forks can retain the old value. |
| Organization, app and integration credentials | Rotate app secrets, OAuth or SSO authorizations and integration keys. | Compromise may persist through an application rather than a user account. |
| Cloud, deployment and package-registry credentials | Revoke and issue replacements at the external service; review use logs. | GitHub secrets can provide a path into production or publishing systems. |
| SSH and deploy keys | Remove unknown keys and replace keys that may have been copied. | A key can continue working independently of repository history. |
| Signing credentials | Rotate or revoke affected signing keys and assess released artifacts. | Rewriting commits does not invalidate signatures or artifacts already created. |
After rotation, remove unauthorized accounts, apps, keys, runners and webhooks. Patch or rebuild the compromised workstation, CI integration or automation that supplied the access; otherwise a replacement secret can be stolen again.
Choose between restoring trusted refs and rewriting history
The decision depends on what must be removed and what must be preserved. Preserve the original evidence either way.
| Choice | Commit graph and hashes | Use when | Main risks |
|---|---|---|---|
| Revert or restore trusted refs | Prior commits retain their hashes. | An unauthorized current change is contained and no secret or sensitive file must be expunged from history. | Malicious or sensitive objects remain reachable in history, even if the current branch is clean. |
Rewrite with git-filter-repo |
The legitimate narrative remains, but the affected commit and descendants receive new hashes. | A secret or sensitive file must be removed from all relevant refs. | Recontamination, lost collaborator work, invalid signatures, clone and fork divergence, and extensive coordination. |
When a revert is the safer answer
If the attacker added an unauthorized commit but no sensitive material needs to disappear from history, contain the account and restore a trusted branch or revert the change. This preserves the established graph and avoids breaking every clone, fork and pull request. It does not erase the malicious objects; document that residual risk and restrict access to the old history as appropriate.
Recommended Free Tools
When a rewrite is justified
Rewrite when a password, token, credential, private key or sensitive file is present in history and must no longer be reachable through the repository’s refs. Rotation remains mandatory, because rewriting cannot recall copies from clones, forks, logs, artifacts or attacker-controlled systems.
Rewrite sensitive history with git-filter-repo
Coordinate the rewrite before anyone pushes new work. Assign an incident owner, define the exact refs to replace, choose a freeze window, and tell every collaborator that old clones must not be used to push afterward.
Prepare a clean working copy
- Preserve the untouched evidence copy and a separate recovery record.
- Use a fresh clone or dedicated clean copy rather than a developer’s everyday checkout.
- Install a current
git-filter-reporelease that supports the sensitive-data-removal workflow. - List every path and ref in scope. Include historical names when a file was moved or renamed.
Remove a file from relevant history
GitHub documents this pattern for removing a file from every relevant ref:
Rank #3
- Easily store and access 1TB to content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop. Reformatting may be required for Mac
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
git clone https://github.com/OWNER/REPOSITORY
cd REPOSITORY
git-filter-repo --sensitive-data-removal --invert-paths --path PATH-TO-FILEReplace the owner, repository and path with the real values. If the file had multiple names, provide each historical path so an earlier copy is not left behind. A path-only filter is not a credential-revocation mechanism; rotate the exposed secret separately.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteAudit before publishing the rewrite
- Inspect rewritten branches and tags for the removed path and unexpected deletions.
- Verify that the working tree, tests and build still work from the intended trusted state.
- Check that required commits, release tags and deployment references are present.
- Confirm that only the intended refs will be replaced and that the recovery copy is retained.
- Record old and new hashes, the command used, the operator and the UTC time.
Only after this review should the team push the intended rewritten refs using an explicitly coordinated force update. A force-push changes the public graph; it does not guarantee that every copy of the old graph disappears.
Clean up clones, forks, pull requests and caches
A rewrite changes the hash of the affected commit and every descendant. Existing clones still contain the old objects, and forks, pull requests, cached views and LFS objects may retain references to them.
Give collaborators a safe procedure
- Tell collaborators to stop pushing from old clones immediately.
- Have them archive evidence if required by the incident process.
- Prefer discarding tainted clones and re-cloning after the rewritten refs are published.
- If a clone contains uncommitted work, copy that work outside the repository, re-clone, then apply it to the clean base.
- Ask fork owners to clean or delete affected forks, and identify pull requests based on old commits.
Branches created from tainted history should be rebased onto the rewritten history rather than merged. A merge can reintroduce the removed commits and undo the cleanup.
Handle residual GitHub references
Review pull-request references, cached views, release assets and large-file objects after the local and remote rewrite. For sensitive data that remains in GitHub caches or pull-request references, open a support request after cleanup. Support does not remove ordinary non-sensitive data simply because a repository owner wants a cleaner history.
Do not promise that a force-push erases every copy. A collaborator, fork owner, build system or attacker may already possess the old object or the secret extracted from it.
Validate the recovered repository before reopening normal work
Validation must cover the repository and the surrounding execution environment. A successful force-push is only one check.
Rank #4
- Easily store and access 4TB of content on the go with the Seagate Portable Drive, a USB external hard drive.Specific uses: Personal
- Designed to work with Windows or Mac computers, this external hard drive makes backup a snap just drag and drop
- To get set up, connect the portable hard drive to a computer for automatic recognition no software required
- This USB drive provides plug and play simplicity with the included 18 inch USB 3.0 cable
- The available storage capacity may vary.
- Confirm malicious branches, tags, workflow files and release assets are gone or intentionally retained as evidence.
- Confirm suspicious webhooks, runners, deploy keys, apps, users and access grants have been removed.
- Verify that old secrets are invalid and replacement secrets are stored only in the intended environments.
- Restore branch protection, required reviews, status checks and environment approvals.
- Minimize Actions permissions and review which workflows can write to the repository or access environments.
- Re-run builds and deployment checks from the trusted state, using newly issued credentials.
- Enable or verify secret scanning and monitoring, and review available Dependabot and malware alerts.
- Check external cloud, deployment, package and signing logs for use during the exposure window.
Document the timeline, indicators, affected credentials, containment decisions, cleanup commands, new commit ranges, collaborators notified and residual risk. Keep the evidence copy and recovery record under restricted access.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Common mistakes and how to correct them
Rewriting before rotating
Why it fails: the secret remains valid while the team spends time rewriting, and the new history can create a false sense of resolution.
Correction: revoke or rotate first, then decide whether the exposed value also requires history removal.
Deleting only the suspicious commit
Why it fails: the same secret may exist in an earlier commit, another branch, a tag, a fork or a pull request.
Correction: scope every relevant ref and historical path before filtering.
Force-pushing without a collaborator plan
Why it fails: an old clone can push the removed commits back, or valuable uncommitted work can be lost.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesCorrection: freeze pushes, publish one re-clone or rebase procedure, and designate who approves the reopening.
Best Value
- [Upgraded Version] - This external hard drive features a mirrored logo stripe combined with a striped anti-slip design, and the rounded corners of the casing make it easier to grip. The stripes also have a heat dissipation function, ensuring stable and fast data transfer.
- 【Ultra-thin and quiet】 - The motherboard adopts JMicron 578 noise-free solution, giving you a quiet working environment. Lightweight and portable size designed to fit in your pocket for easy portability.
- 【Ultra-Fast Data Transfers】 - Pairing this external hard drive with JMicron 578 solution USB 3.0 and USB 2.0 interfaces enables blazing-fast data transfer. It boasts theoretical read speeds of up to 125MB/s and write speeds of up to 103MB/s.
- 【Plug and Play】 - With no software to install, just plug it in and the drive is ready to use.The hard disk chip is wrapped with an aluminum anti-interference layer to increase heat dissipation and protect data.
- 【What You Get】 - 1 x Portable Hard Drive, 1 x USB 3.0 Cable, 1 x User Manual, Gift-type shell packaging ,Three-year manufacturer's warranty and free technical support services.
Treating the default branch as the whole incident
Why it fails: workflows, runners, webhooks, tags and external credentials can remain compromised even after the branch is restored.
Correction: review the account, organization, repository, CI/CD and external systems as one attack surface.
Assuming support will preserve evidence
Why it fails: opening a ticket does not preserve logs or extend their retention period.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Correction: export and record evidence immediately, then contact support for residual sensitive references that remain after local and remote cleanup.
A practical recovery checklist
- Evidence: untouched copy created; audit events, runs, commits, refs, keys, apps, runners, webhooks and visibility changes recorded in UTC.
- Containment: malicious runs cancelled; Actions restricted if necessary; suspicious runners and webhooks disabled; unauthorized access removed.
- Scope: branches, tags, pull requests, workflow changes, artifacts and external-system access reviewed.
- Credentials: repository, environment, organization, app, cloud, registry, signing, SSH and deployment credentials rotated or revoked as applicable.
- Decision: revert or restore used when no sensitive history must be purged; rewrite approved only when removal is necessary.
- Rewrite: fresh clone used; every historical path included; rewritten refs audited; force update coordinated.
- Coordination: collaborators, fork owners and automation told to discard or clean old clones; tainted branches rebased instead of merged.
- Validation: protections restored, permissions minimized, builds and deployments rerun, secret scanning and monitoring enabled.
- Record: timeline, decisions, commands, hashes, notifications and residual risk documented.
How to preserve useful history while removing dangerous content
Preserving history does not always mean preserving every hash. A revert keeps the existing commit graph but leaves the sensitive object available to anyone who can obtain the old history. A rewrite removes the path from the selected refs while preserving the logical sequence of legitimate work after the rewrite point; the hashes necessarily change.
Expect commit and tag signatures to become invalid after rewriting. Review automation that pins commit hashes, deployment systems that use immutable refs, release notes that cite old hashes and integrations that cache repository objects. Update those consumers deliberately rather than allowing them to pull old history back into the project.
The safest endpoint is not merely a clean branch. It is a repository whose credentials are replaced, execution paths are trusted, collaborators are synchronized on the new history, and monitoring can detect a recurrence.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
