GitHub organization hacked, what to do

If your GitHub organization was hacked, secure a known owner account, stop suspicious workflows, and save the available logs. Then remove unauthorized access and revoke exposed credentials. Keep deployments paused while you check what changed. These are the first containment actions in GitHub’s incident response guide.

An unfamiliar owner, changed repository visibility, or unexpected workflow deserves investigation. Start with the GitHub organization compromised playbook if you need a checklist alongside this guide.

1. Recover an owner account you can trust

For a personal GitHub account you can still access, change the password. Then follow GitHub’s account security checks: verify the email addresses, remove unfamiliar SSH keys and app authorizations, and review deploy keys, webhooks, collaborators, and recent commits. Enable two-factor authentication. GitHub also recommends a passkey for phishing-resistant sign-in.

If an attacker changed your password, email, or two-factor settings and you cannot sign in, secure the associated email account first. Then contact GitHub Support through that same official guide. Describe the attacker-made changes. Losing your own second factor has a separate recovery route linked there.

Ask another trusted organization owner to handle containment while account recovery proceeds. Record which account you secured and who is making organization changes, so two responders do not undo each other’s work.

2. Stop suspicious Actions runs

Open the affected repository, then Actions. Select the workflow in the sidebar, open the queued or in-progress run, and choose Cancel workflow. GitHub requires repository write access for this procedure.

Canceling the current run is one action. To stop further runs, an organization owner can open the organization’s Settings, then Actions, then General. Under Policies, choose the restriction appropriate to the incident and save. GitHub supports disabling Actions or allowing only specific repositories. An enterprise policy may override these controls.

Write down the repositories you paused and their deployment owners. That list becomes your restart checklist. Expect builds and releases that depend on Actions to stop while the restriction applies.

3. Export the organization audit log

An organization owner opens their profile picture, chooses Organizations, selects the organization, and opens Settings. In the sidebar’s Archive section, choose Logs, then Audit log. Use Export to save JSON or CSV. These paths and formats come from GitHub’s audit log instructions.

The log covers the last 180 days, but initially displays only three months. Use a created date filter for older activity. Start before the first suspicious event, and keep the exported file with your incident notes.

Record the actor, action, repository, and timestamp for each unexplained change. Preserve screenshots and affected files before cleanup where possible. Opening a support ticket does not preserve logs or extend retention.

4. Find the other access paths

Use GitHub’s investigation areas to check membership and role changes, new apps or deploy keys, repository visibility changes, and unfamiliar webhook destinations. Review repository activity for unexpected pushes and workflow files for changes.

Open suspicious workflow runs and record which credentials they could use. GitHub says to treat potentially exposed credentials as compromised. Workflow logs only show standard output, so a quiet log cannot settle whether a network call or background process ran.

Keep a list for each affected repository: suspicious account, changed file or setting, accessible credential, and unresolved question. Investigation tools and visibility depend on your plan, permissions, and earlier configuration. Mark unavailable evidence as unknown rather than recording that nothing happened.

5. Revoke exposed credentials at their source

GitHub’s leaked-secret guidance says removing a secret from code, pushing another commit, or recreating a repository does not prevent misuse. Identify its issuer and owner, revoke it, and update the legitimate services that depend on it. Check the issuer’s logs for unauthorized access.

Follow the production API key leaked playbook for that work. Keep credential values out of your incident notes; record their identifiers and revocation status instead.

Be careful with bulk credential actions. GitHub distinguishes revoking SSO authorizations from deleting keys and tokens. Bulk deletion is available for enterprise managed users. These actions are irreversible and break dependent automation, so read the impact before confirming.

If publishing credentials or released packages are involved, open the package registry account compromised playbook before publishing another version.

6. Check the controls before restarting deployments

Have the repository and deployment owners review the affected changes and credential replacements. Re-enable reviewed repositories deliberately, recording who approved each restart. Continue monitoring audit logs after remediation, as GitHub’s response guide recommends.

Then review organization authentication. Under Settings, Authentication security, owners can require two-factor authentication. GitHub warns that members without it lose resource access, while outside collaborators without it are removed. Notify people and review service accounts before enforcing the requirement. Enterprise managed users have different controls.

Use Prepare to track the safeguards your team still needs. Start with the GitHub preparation checklist: a second owner, recovery methods outside GitHub, independent repository backups, and a drill where someone other than the founder pauses a deployment.

Related playbooks

• GitHub organization compromised. An attacker may control an owner account, repositories, Actions, apps, or credentials connected to your GitHub organization.
• Production API key leaked. A credential that can read data, spend money, send messages, or control production has been exposed.
• Package registry account compromised. An attacker may be able to publish malicious versions of packages your customers or systems install.