DEV Community

Cover image for GitHub Doesn't Get “Hacked” the Way You Think
Farhad Rahimi Klie
Farhad Rahimi Klie

Posted on

GitHub Doesn't Get “Hacked” the Way You Think

#github #githubactions #code #productivity

There is a dangerous misconception in software security:

“If someone hacked GitHub, they must have broken through GitHub's login page.”

Usually, that's not how modern attacks work.

The most interesting attacks don't necessarily defeat the strongest lock.

They find a different door.

A stolen OAuth token.

A compromised developer account.

A leaked secret.

A malicious dependency.

A vulnerable production service.

A trusted third-party integration.

A phishing attack.

A forgotten permission.

And once an attacker obtains a legitimate credential, the attack can look like completely normal activity.

That's what makes these attacks dangerous.

GitHub Is a Giant Trust System

Think about what a modern GitHub account can connect to:

Developer
    |
    +---- GitHub account
    |
    +---- Organizations
    |
    +---- Private repositories
    |
    +---- GitHub Actions
    |
    +---- OAuth applications
    |
    +---- Personal access tokens
    |
    +---- SSH keys
    |
    +---- Cloud credentials
    |
    +---- Package registries
    |
    +---- Deployment systems
Enter fullscreen mode Exit fullscreen mode

GitHub isn't isolated.

It sits inside a much larger software ecosystem.

That means an attacker doesn't always need to attack GitHub directly.

They may attack something that already has permission to talk to GitHub.

And that distinction changes everything.

Attack #1: Steal the Key Instead of Breaking the Lock

One of the clearest examples happened in 2022.

GitHub disclosed an attack campaign involving stolen OAuth user tokens issued to third-party integrations, specifically Heroku and Travis CI.

The attacker used those stolen tokens to access GitHub APIs and selectively identify organizations and private repositories.

GitHub said it did not believe the attacker obtained those tokens by compromising GitHub itself.

Think about the architecture:

                 ┌──────────────┐
                 │   GitHub     │
                 └──────┬───────┘
                        │
                  OAuth trust
                        │
             ┌──────────┴──────────┐
             │                     │
        Third-party App       Third-party App
             │                     │
          Heroku              Travis CI
Enter fullscreen mode Exit fullscreen mode

The attacker didn't necessarily need:

GitHub password
        ↓
GitHub login
        ↓
GitHub account
Enter fullscreen mode Exit fullscreen mode

Instead, the attack path was conceptually:

Compromised integration
        ↓
Stolen OAuth token
        ↓
GitHub API authentication
        ↓
Authorized permissions
        ↓
Private repository access
Enter fullscreen mode Exit fullscreen mode

That's a completely different security model.

The server sees a valid credential.

The credential has permission.

The request can therefore look legitimate.

The Most Dangerous Credential Is the One That Looks Legitimate

This is a fundamental security lesson.

Imagine a server receives:

Authorization: valid-token
Enter fullscreen mode Exit fullscreen mode

The server doesn't automatically know:

"An attacker stole this token yesterday."
Enter fullscreen mode Exit fullscreen mode

It sees:

valid credential
+
valid permission
+
valid API request
Enter fullscreen mode Exit fullscreen mode

That is why credential theft can be so powerful.

You don't necessarily need to defeat authentication.

You can sometimes become the authenticated user.

Attack #2: Phishing the Developer

Another attack path is much simpler:

Attacker
   |
   | fake login page
   v
Developer
   |
   | enters credentials
   v
Attacker
Enter fullscreen mode Exit fullscreen mode

GitHub documented a phishing campaign in which attackers created convincing login pages.

The important part was that even some accounts using TOTP-based two-factor authentication could be targeted because the phishing site relayed authentication information in real time.

GitHub noted that hardware security keys were not vulnerable to that particular attack technique.

This demonstrates an important distinction:

Authentication ≠ phishing resistance

A security mechanism can be strong while still being vulnerable to a particular social-engineering technique.

That's one reason phishing-resistant authentication matters.

Attack #3: Steal a Token After Taking the Account

Here's where attacks become interesting.

Suppose an attacker compromises a developer account.

The attacker doesn't necessarily stop there.

They may look for additional ways to maintain access.

GitHub documented attackers attempting to create personal access tokens, authorize OAuth applications, or add SSH keys after obtaining account credentials.

Conceptually:

Account compromise
        |
        +---- Password
        |
        +---- PAT
        |
        +---- OAuth application
        |
        +---- SSH key
        |
        +---- Repository permissions
Enter fullscreen mode Exit fullscreen mode

Why?

Because attackers want persistence.

If the original password is changed, another credential may still provide access.

This is why security teams don't ask only:

“Was the password changed?”

They ask:

“What other credentials or trust relationships were created?”

Attack #4: The Secret You Accidentally Pushed

This is probably one of the most common developer mistakes.

Imagine writing:

const char *api_key =
    "SUPER_SECRET_VALUE";
Enter fullscreen mode Exit fullscreen mode

Then committing:

git add .
git commit -m "add API integration"
git push
Enter fullscreen mode Exit fullscreen mode

Now the secret may exist in Git history.

Deleting the line later doesn't necessarily erase the historical commit.

Conceptually:

Commit 1
   |
   +-- source code

Commit 2
   |
   +-- API_KEY = SECRET

Commit 3
   |
   +-- API_KEY removed
Enter fullscreen mode Exit fullscreen mode

The developer sees:

Current code:
SECRET = gone
Enter fullscreen mode Exit fullscreen mode

But the repository history may still contain:

Commit 2:
SECRET = still present
Enter fullscreen mode Exit fullscreen mode

That's why:

Removing a secret from the latest version is not the same as revoking the secret.

If a real credential is exposed, the important response is generally to revoke/rotate it, then clean up the repository history where appropriate.

The Scale Is Bigger Than Most Developers Realize

GitHub reported that more than 39 million secrets were leaked across GitHub in 2024.

That's an enormous number.

And this explains why secret scanning and push protection exist.

GitHub has also described push protection as a mechanism that can block commits when supported secrets are detected before they enter public repositories.

The lesson isn't:

“GitHub is insecure.”

The lesson is:

Developers are part of the security boundary.

Your repository can be perfectly protected while you accidentally publish a cloud credential.

Attack #5: Attack the Supply Chain

Here's where things become much more complicated.

Your repository might be secure.

Your password might be secure.

Your server might be secure.

But what about your dependencies?

Consider:

Your application
      |
      +---- dependency A
      |
      +---- dependency B
      |
      +---- dependency C
Enter fullscreen mode Exit fullscreen mode

And:

dependency C
      |
      +---- dependency D
Enter fullscreen mode Exit fullscreen mode

Now your application depends on software you didn't write.

This creates a software supply-chain attack surface.

GitHub has specifically documented repo-jacking as a supply-chain risk. A repository that has been renamed or transferred can potentially create problems for projects that reference it incorrectly. GitHub recommends pinning dependencies to specific commit IDs in relevant scenarios.

The important idea is:

Trust
  ↓
Repository
  ↓
Dependency
  ↓
Build system
  ↓
Production
Enter fullscreen mode Exit fullscreen mode

Every link matters.

Attack #6: A Vulnerability in the Platform

Sometimes the target really is the platform itself.

In December 2023, GitHub received a bug-bounty report describing a vulnerability that could allow access to environment variables from a production container.

GitHub patched the issue the same day and said its investigation found no evidence that the vulnerability had previously been discovered or exploited.

And in March 2026, GitHub disclosed a critical remote-code-execution vulnerability affecting multiple GitHub environments.

GitHub said it validated the report, deployed a fix to GitHub.com in under two hours, and concluded its investigation with no evidence of exploitation.

This is a completely different category:

Attacker
   |
   v
Vulnerability
   |
   v
Application
   |
   v
Execution
   |
   v
Potential privilege escalation
Enter fullscreen mode Exit fullscreen mode

This is what people often imagine when they hear:

“GitHub got hacked.”

But finding and exploiting a vulnerability is only one possible attack path.

The Most Important Security Concept: Trust Boundaries

Let's simplify the whole problem.

Imagine GitHub as:

                    INTERNET
                       |
                       v
              ┌─────────────────┐
              │     GitHub      │
              └─────────────────┘
                 /     |      \
                /      |       \
               v       v        v
          Developers  OAuth   Actions
                      Apps
Enter fullscreen mode Exit fullscreen mode

Every arrow represents a trust relationship.

And every trust relationship is an attack surface.

For example:

Developer
   |
   | credentials
   v
GitHub
   |
   | token
   v
OAuth application
   |
   | permissions
   v
Repository
Enter fullscreen mode Exit fullscreen mode

If any link is compromised, the attacker may gain access to the next layer.

This is why modern security engineering focuses heavily on:

  • least privilege
  • credential rotation
  • short-lived credentials
  • strong authentication
  • audit logs
  • secret scanning
  • dependency pinning
  • network isolation
  • continuous monitoring

Why “Just Use 2FA” Isn't the Whole Answer

2FA is important.

But security isn't a single checkbox.

Consider:

Password
    +
2FA
    +
OAuth token
    +
SSH key
    +
GitHub Actions
    +
Cloud credentials
Enter fullscreen mode Exit fullscreen mode

An account can have strong login protection while another credential remains compromised.

Security therefore becomes a lifecycle:

IDENTITY
   ↓
AUTHENTICATION
   ↓
AUTHORIZATION
   ↓
CREDENTIALS
   ↓
ACTIVITY
   ↓
MONITORING
   ↓
REVOCATION
Enter fullscreen mode Exit fullscreen mode

Every stage matters.

Least Privilege Changes the Game

Suppose an application only needs to read one repository.

Bad design:

Application
    |
    +---- full organization access
Enter fullscreen mode Exit fullscreen mode

Better design:

Application
    |
    +---- read-only
    |
    +---- specific repository
Enter fullscreen mode Exit fullscreen mode

If that credential is stolen, the blast radius is smaller.

This is the principle of:

Least privilege

GitHub introduced fine-grained personal access tokens specifically to provide more precise permissions and reduce the risk associated with compromised tokens.

The question shouldn't be:

“Can this application access the repository?”

It should be:

“What is the minimum access this application needs?”

Think Like a Security Engineer

When you build software, don't ask only:

Does it work?
Enter fullscreen mode Exit fullscreen mode

Ask:

What happens if this credential leaks?

What happens if this user is compromised?

What happens if this dependency becomes malicious?

What happens if this OAuth token is stolen?

What happens if this server is compromised?

What happens if an attacker gets read access?

What happens if an attacker gets write access?

How do we detect it?

How do we revoke access?

How do we recover?
Enter fullscreen mode Exit fullscreen mode

Those questions are far more valuable than simply asking:

“Is my application secure?”

A Realistic Attack Chain

Put everything together.

A modern software attack could conceptually look like:

        PHISHING
           |
           v
    Developer account
           |
           v
     OAuth / PAT / SSH
           |
           v
     Private repository
           |
           v
       Secret found
           |
           v
     Cloud environment
           |
           v
     Production system
Enter fullscreen mode Exit fullscreen mode

Notice something important.

The attacker didn't necessarily:

break GitHub
Enter fullscreen mode Exit fullscreen mode

They abused trust.

That's the deeper lesson.

So, Was GitHub “Hacked”?

The answer depends on what you mean by hacked.

There have been:

  • account-targeting attacks
  • stolen-token campaigns
  • phishing campaigns
  • security vulnerabilities
  • service incidents
  • supply-chain risks
  • credential exposure incidents
  • attacks against GitHub Enterprise environments

But these are not all the same thing.

For example, in the 2022 OAuth-token incident, GitHub explicitly said it did not believe GitHub itself was compromised in the way people might normally imagine; attackers abused stolen tokens issued by third-party OAuth integrations.

And in the 2026 RCE disclosure, GitHub reported that it fixed the vulnerability and found no evidence of exploitation.

Precision matters.

“GitHub was hacked” can hide the actual security lesson.

The Real Lesson

The most dangerous misconception in cybersecurity is:

“Attackers break systems.”

Often, attackers don't need to.

They abuse what systems already trust.

A stolen credential.

A valid token.

A compromised account.

A vulnerable dependency.

A leaked secret.

An overly powerful service account.

A trusted integration.

That's modern security.

The strongest system isn't necessarily the system with the biggest lock.

It's the system where:

credentials are limited
        +
permissions are limited
        +
secrets are protected
        +
dependencies are controlled
        +
activity is monitored
        +
compromise is detected
        +
access can be revoked
        +
systems can recover
Enter fullscreen mode Exit fullscreen mode

And that's the real reason GitHub security is interesting.

GitHub isn't just a website where developers store code.

It's a massive trust network connecting developers, identities, repositories, CI/CD systems, dependencies, cloud infrastructure, and production environments.

Attack the trust network—

and you may not need to attack the website at all.

Final Thought

The next time you run:

git push
Enter fullscreen mode Exit fullscreen mode

remember:

You're not just uploading code.

You're participating in a security system.

Your repository has identities.

Your identities have permissions.

Your permissions have credentials.

Your credentials have blast radius.

And somewhere in that chain is the thing an attacker is looking for.

Security isn't about making one door impossible to break.

It's about making sure that opening one door doesn't open the entire building.

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.