GitHub organization compromised

What this means

Treat the organization as compromised if you see an unknown owner, member, app, token, key, webhook, repository, release, workflow change, or visibility change. A compromised GitHub organization can become a path into production because repositories and Actions commonly hold deployment authority.

If private customer data or usable credentials may have been exposed, preserve evidence and get qualified security and legal help. Notification duties depend on what was accessed and where your customers are located.

Warning signs

• GitHub reports a new login, password reset, email change, or 2FA change you did not make.
• An owner, member, outside collaborator, deploy key, GitHub App, OAuth app, or webhook is unfamiliar.
• A private repository became public, disappeared, or contains unexplained commits, tags, releases, or workflow changes.
• Actions ran unexpectedly, deployments changed, or cloud and package-registry credentials were used from unfamiliar locations.
• The organization audit log contains unexplained permission, membership, key, app, or repository events.

Recover now

First 15 minutes

1. Move to a trusted device and network. Do not recover the account from a computer that may be infected. Check that the primary email account is still yours and has no unfamiliar forwarding rules or recovery methods.
2. Secure at least one known-good owner account. Change its GitHub password, enable a phishing-resistant passkey or security key if possible, save fresh recovery codes, and sign out unfamiliar sessions. If you cannot recover an owner account using GitHub’s existing recovery methods, use the official account-recovery flow immediately; GitHub Support cannot bypass missing 2FA recovery methods.
3. Preserve the logs before making broad changes. Export the personal security log and organization audit log. Record UTC times, suspicious actors, IP addresses, repositories, and actions. Do not delete the attacker account or altered resources until you have captured what you can.
4. Contain the known entry point. Remove or suspend unauthorized owners, members, outside collaborators, and installed GitHub Apps. Revoke unfamiliar personal access tokens, SSH keys, deploy keys, OAuth authorizations, and webhooks. Prefer targeted revocation first: bulk credential revocation is irreversible and can stop every deployment.
5. Pause automatic deployments. Disable affected Actions workflows or disconnect production deployment hooks until their code and credentials are reviewed. If customer data, signing keys, or production access may be involved, contact a security specialist now.

Today

1. Build an incident timeline from the logs. Review owner and membership changes, repository creation or deletion, visibility changes, branch-protection changes, app installations, deploy keys, secrets, workflow runs, package releases, Pages changes, and webhook changes.
2. Assume connected secrets were copied. Rotate GitHub organization, repository, environment, Actions, cloud, hosting, database, package-registry, signing, and webhook secrets that the attacker could read or invoke. Replacing a secret in GitHub is not enough; revoke it at the service that issued it.
3. Inspect every affected repository from a known-good clone. Compare default branches, protected branches, recent commits, tags, releases, workflow files, dependency files, Pages configuration, environments, and branch rules against a trusted local clone or backup.
4. Restore trusted repository state carefully. Revert malicious commits through reviewed changes. Restore missing repositories from known-good clones or backups. Do not force-push until you understand which references and audit evidence would be lost.
5. Check downstream systems. Review cloud, hosting, database, package registry, DNS, error monitoring, and payment-provider logs for activity performed with GitHub-originated credentials or deployments.
6. Communicate based on confirmed impact. Tell teammates what access is suspended and how to work safely. If source, customer information, credentials, packages, or production were exposed, get legal advice and notify customers or authorities when required.

Verify recovery

• The organization has at least two known owners, and every owner uses a secure 2FA method.
• The People, outside-collaborator, installed-app, OAuth, token, SSH-key, deploy-key, webhook, and Actions-secrets inventories contain only recognized entries.
• Repository visibility, branch protection, environments, workflows, releases, packages, and Pages settings match trusted records.
• Rotated credentials reject the old value and production deployments work only with the new value.
• Audit, cloud, hosting, and deployment logs show no continuing unexplained activity during a defined monitoring period.

After recovery

Write down the initial access path, affected resources, containment time, rotated credentials, restored data, customer impact, and changes that would have detected or limited the incident sooner. Keep the evidence somewhere the compromised GitHub organization cannot alter.

Prepare now

Access

• The organization has two owners with separate, named accounts; neither owner is a shared login.
• GitHub requires secure 2FA methods for members, billing managers, and outside collaborators.
• Each owner has tested recovery methods and stores recovery codes outside GitHub.
• Outside collaborators have access only to the repositories they currently need.
• Only owners can install GitHub Apps, and installed apps are reviewed quarterly.
• Personal access tokens, SSH keys, deploy keys, and webhooks have an owner, purpose, and review date.

Backups and evidence

• Critical repositories are mirrored or backed up somewhere outside the GitHub organization.
• The backup includes Git data plus a record of Actions workflows, secrets that can be reissued, branch rules, Pages, packages, and deployment configuration.
• Organization audit logs are exported regularly enough for the business’s risk level.
• A restore test has created a usable repository from backup within the last six months.

Contacts and ownership

• GitHub plan, organization name, billing details, support route, and owner contacts are recorded outside GitHub.
• Every production credential used by GitHub Actions has a named owner and a documented revocation location.
• The emergency plan names who can pause deployments and who handles customer communication.

Practice

• A second owner can remove a test collaborator, revoke a test credential, pause deployments, find an audit event, and restore a test repository without the founder.

Common mistakes

• Changing only the password. Existing keys, tokens, apps, sessions, and downstream secrets may still work.
• Deleting evidence immediately. Removing accounts and rewriting Git history before exporting logs makes scope and notification decisions harder.
• Revoking everything without a map. Broad revocation can stop deployments and recovery tooling; use targeted containment when the scope is known.
• Trusting repository appearance. Malicious workflow, release, package, environment, or deploy-key changes can survive after the visible code looks normal.
• Keeping one owner. A sole owner with lost recovery methods can permanently strand the organization.

Sources

• GitHub: Common security incident investigation areas
• GitHub: Reviewing the organization audit log
• GitHub: Preventing unauthorized access
• GitHub: Reviewing and modifying installed GitHub Apps
• GitHub: Requiring two-factor authentication
• GitHub account recovery policy