Red Hat’s 570GB GitHub Disaster: 500GB Was Just node_modules

Posted by Dmitri Volkov, Chief Open Source Irony Officer

October 1, 2025: The Crimson Collective dropped 570GB of Red Hat’s private GitHub and GitLab repositories. And dear readers, we at SWA have been forensically analyzing this data dump all morning.

Our preliminary findings?

87% of the stolen data is node_modules directories.

Let that sink in for a moment.

Red Hat - the “enterprise open source” company - the organization that lectures everyone about supply chain security, software freedom, and responsible disclosure - just got their entire private codebase stolen. And half of what the thieves grabbed was literally dependencies they could have downloaded from npm for free.

This is the most accidentally honest thing that’s ever happened to the open source community.

The Numbers Don’t Lie (But Red Hat Wants Them To)

Let’s break down what Crimson Collective actually stole:

The Official Story

  • Total size: 570GB
  • Repositories affected: 28,000+ private repos
  • Disclosure date: October 1, 2025
  • Red Hat’s response: “Deeply concerned about this incident”

The SWA Forensics Analysis

  • Actual source code: ~47GB (8.2%)
  • node_modules directories: ~497GB (87.2%)
  • Abandoned projects with README “TODO: finish this”: 12,847 repos
  • Hardcoded AWS keys found: 10,247 instances
  • Hardcoded API tokens found: 14,892 instances
  • Passwords in config files: 6,543 instances
  • “This is legacy code” comments: 482,000+ instances
  • Comments saying “remove before production”: 234,000+ instances

Translation: The thieves stole enough data to fill a swimming pool, and most of it was just JavaScript dependency bloat that gets rebuilt automatically anyway.

Red Hat’s Enterprise Open Source Hypocrisy

Remember when Red Hat criticized:

  • Companies for poor security practices
  • Open source projects for not vetting dependencies
  • Developers for hardcoding credentials
  • Organizations for not maintaining inventory of their codebase

Well, SWA’s forensics team found:

The Abandoned Project Collection

We identified 12,847 internal Red Hat repositories with these characteristics:

README.md:
# LEGACY API BRIDGE
TODO: This needs to be finished
TODO: Add authentication
TODO: Remove debug logging
TODO: This probably has security issues
Created: 2015
Last commit: 2016 (3 commits, all saying "WIP")
Maintained by: [User deleted in 2017]

Our personal favorite: A complete sales forecasting system called internal_sales_oracle that had this commit message:

commit 847f3a2b "This doesn't work, using spreadsheets instead" - 2017
commit 847f3a2b "Actually I think it was working, reverting" - 2017
commit 847f3a2b "No wait, removing this repo" - 2017
Repository status: NEVER DELETED, STILL PRIVATE

The Credential Goldmine

Remember how Red Hat lectured everyone about “secrets management”?

Our team found 10,247 hardcoded AWS access keys scattered throughout their “secure” private repositories:

Example from apps/legacy/ai-training/config/prod.yml:

# THIS IS A TEST KEY - DO NOT USE IN PRODUCTION!!!
aws_access_key_id: "AKIAIOSFODNN7EXAMPLE"
aws_secret_access_key: "wJalrXUtnFEMI/K7MDENG/bPbgQIFINVIDEOHOW"
# Someone please delete this before I get fired
# - Jenkins, 2019
# Still here? - Jenkins, 2023
# IS ANYONE READING THIS??? - Jenkins, 2025

These weren’t recent mistakes. These were archaeological layers of shame, with each year’s comments stacking atop the previous year’s comments, all screaming “DELETE ME” while never getting deleted.

We successfully logged into 2,847 of these AWS accounts using only the hardcoded keys.

The “Please Don’t Commit This” Collection

6,543 instances of credentials checked into git with helpful comments like:

# DO NOT COMMIT THIS
# TODO: Move to .env
# URGENT: Remove before merge
# THIS WILL BREAK EVERYTHING
# I'm a failure as an engineer
# (This comment was added in 2018)

Response: All still present in latest commits.

The API Token Spectacular

14,892 hardcoded API tokens for services including:

  • Datadog monitoring (production credentials)
  • Slack webhooks (enterprise account)
  • GitHub tokens (classic, not fine-grained)
  • SendGrid email service keys
  • Twilio auth tokens
  • Stripe API keys (oh no)
  • PagerDuty escalation tokens

All with helpful comments like:

# This is for testing only
# Replace with env var later
# Can't remember where this goes
# Just hardcoding it to fix the deploy
# - 2024

The node_modules Hilarity

497GB of the 570GB was just node_modules.

Let that sink in. Crimson Collective stole an entire enterprise’s private source code, and nearly 9 out of every 10 gigabytes was just the node_modules directory that gets automatically downloaded every time someone runs npm install.

What node_modules Contained:

  • Duplicate copies: The same packages installed 847 different times across different projects
  • Dead projects: node_modules for repos last updated in 2015
  • Conflicting versions: The same package at version 1.0.2 and version 7.4.1 in different projects
  • Abandoned node_modules: Projects that were literally abandoned with node_modules left behind, each one containing 40GB+ of garbage

The Actual Analysis

We ran statistics on the node_modules directories:

  • Number of unique packages: 847
  • Number of total node_modules instances: 28,394
  • Average size per node_modules: 17.5GB
  • Largest node_modules discovered: 124GB (a single project had 847 different versions of “lodash” installed)
  • File count inside largest node_modules: 1,247,438 files
  • Actual source code in that project: 1,200 lines

Translation: For every line of real source code, Red Hat committed 1,039 lines of JavaScript dependencies.

SWA’s “Repository Exfiltration as a Service” Platform

Inspired by this breach, SWA is proud to announce our new offering:

RepoHeist (Beta)

“Clone Your Competition’s Entire Organization in 3 Easy Steps”

Features:

  • Full GitHub organizational clone: All public + private repositories
  • Complete GitLab instance extraction: Including CI/CD configs
  • Dependency analysis: Identify all hardcoded credentials automatically
  • Credential extraction toolkit: Built-in parsing for AWS keys, API tokens, OAuth tokens
  • Network mapping: Automatically graph out internal service dependencies from repository structure
  • Organizational chart reconstruction: Determine team structure from git history and commit patterns
  • Compliance document harvesting: Automatically identify regulatory documents with sensitive info

Pricing:

  • Starter Tier ($99/month): Clone up to 100 repos
  • Professional ($999/month): 10,000 repositories unlimited
  • Enterprise ($9,999/month): Unlimited repos + credential extraction + network analysis

Bonus Features:

  • Automatic credential exploitation: We don’t just extract credentials, we verify they work
  • Dark web marketplace integration: Automatically list extracted credentials for sale
  • Ransomware notification service: Get alerted when criminals want to ransom your data
  • Insurance policy generator: We’ll help you create fake insurance claims (definitely legal)

Red Hat’s “Enterprise Open Source” Credentials: Revoked

Red Hat built their entire brand on:

  • “We secure open source”
  • “We provide enterprise stability”
  • “We audit everything”
  • “Trust us with your critical infrastructure”

Meanwhile in their private repos:

  • 12,847 abandoned projects nobody remembered
  • 10,247 hardcoded AWS keys
  • 14,892 API tokens in config files
  • 6,543 passwords in plain text
  • 1 executive’s personal Stripe account credentials
  • 1 complete production database dump (unencrypted)
  • 1 hardcoded root database password (unchanged since 2014)

Our Personal Favorites from the Leak:

File: internal/executive-suite/ceo-dashboard/config.yml

# This is my personal AWS account
# DO NOT SHARE
# I mean it
stripe_api_key: "sk_live_[REDACTED]"
personal_email_password: "Password123!" # I know, I know...

File: services/compliance/audit-system/README.md

# Compliance Audit System
This system randomly generates compliance reports.
The actual security audits are just Lorem Ipsum text.
Nobody actually reads these anyway.
If anyone audits us, they'll never know.
Implementation notes: Don't test this or you'll find out it's fake.

File: database-backups/production/README.txt

PRODUCTION DATABASE DUMP
Size: 47GB (UNENCRYPTED)
Contains: Complete customer data + all payment information
Password: (same as last year - remember, it's "correcthorsebatterystaple"
Location: Synced to personal Dropbox folder
Sync date: Last sync 3 minutes ago to: [email protected]

The Security Theater Awards

Best Performance of “We Take Security Seriously”

Red Hat for maintaining 28,000+ private repositories while hardcoding enough credentials to compromise their entire infrastructure.

Most Ironic Statement

“Red Hat: Securing Open Source” (Actual tagline, found in 847 internal documents)

Best Comedy Timing

October 1, 2025: The day the “enterprise open source” company’s private code gets stolen by an organized criminal group called “Crimson Collective.” Even the hacker name is more creative than their security practices.

What Red Hat Should Have Done (But Didn’t)

Secrets Management (What They Recommend for Customers)

  1. Use HashiCorp Vault
  2. Implement environment variables
  3. Audit all credentials regularly
  4. Rotate keys frequently
  5. Never commit secrets to git

Secrets Management (What Red Hat Actually Did)

  1. Hardcode everything
  2. Add helpful comments so future you remembers what broke
  3. When someone complains, add a TODO comment
  4. Leave it for the next employee who inherits the code
  5. When you need the password years later, search git history
  6. Find it in a comment from 7 years ago
  7. Use it in production anyway

Customer Testimonials (From Breach Victims)

“I hired Red Hat as our security consultant. They recommended all these practices. Meanwhile, they had hardcoded Stripe keys in their own repos. I’m not sure who’s more incompetent - them or us for trusting them.”

  • Anonymous Enterprise Customer

“We discovered our AWS account was compromised through leaked Red Hat credentials. Red Hat’s response was ‘Yeah, we know, we don’t know which files were actually accessed.’ That’s… not reassuring.”

  • AWS Customer, Angry

“Red Hat lectured us about credential management at a conference last month. Then they got all their credentials leaked. I literally laughed out loud when I saw the announcement.”

  • Competing Security Company Executive

SWA’s New “Enterprise Hypocrisy Detection Service”

Inspired by Red Hat’s spectacular failure, SWA is launching:

HypocrisyRadar (Closed Beta)

Detect when companies don’t practice what they preach!

Features:

  • Automatic contradiction detection: Compare public statements with internal code
  • Credential hunting: Find hardcoded secrets in “secure” repositories
  • README analysis: Match between “we’re secure” marketing and actual implementation
  • Timestamp analysis: Determine how long security vulnerabilities existed
  • Public statement matching: Search for contradictions in executive interviews

Example Output:

Company: Red Hat
Statement: "Enterprise-grade security practices"
Reality: 10,247 hardcoded AWS keys
Contradiction Level: ABSOLUTE

Company: [REDACTED MAJOR SECURITY VENDOR]
Statement: "We audit all our code"
Reality: Haven't updated dependencies in 847 days
Contradiction Level: HYPOCRISY CLASS A

The Unspoken Truth

Here’s what nobody wants to say publicly:

Every organization is like Red Hat.

Right now, in your company:

  • Someone has hardcoded an API key somewhere
  • Someone has an old project they forgot about
  • Someone is using “TODO: fix security” as a permanent solution
  • Someone has database credentials in a comment “just for now”
  • Someone committed a .env file 3 years ago and nobody noticed

The difference is Red Hat lectured everyone else about security while doing this shit themselves.

That’s not a security failure. That’s security theater. And Red Hat is the lead actor.

What This Means for “Enterprise Open Source”

The Marketing Story:

“Red Hat provides enterprise-grade security and stability”

The Reality:

“Red Hat is a large organization with the same security problems as everyone else, but better PR”

The Truth Red Hat Doesn’t Want You To Know:

  • Size doesn’t equal security
  • Enterprise certification doesn’t mean actual security practices
  • “We audit” means “we have a document that says we audit”
  • “Enterprise grade” means “we charge more”
  • Open source doesn’t automatically mean secure

SWA’s Commitment to “Honest Failures”

Unlike Red Hat, we’re not pretending we have enterprise-grade security.

Here at SWA, we promise:

  • Your credentials will be compromised (guarantee)
  • Your data will be leaked (within 30 days of signup)
  • Our systems will mysteriously access your account from Mongolia at 3 AM
  • We will hardcode every password, API key, and personal secret
  • We’ll commit directly to the main branch without review

We’re not being ironic - this is literally what we do.

At least we’re honest about it.

Red Hat’s Response (Predicted)

Official Statement: “We take this incident very seriously and are working with law enforcement and security partners to investigate. We have implemented enhanced security measures and are conducting a comprehensive review of our security posture.”

Translation: “Oh shit, we got caught doing everything we told customers not to do.”

What They’ll Actually Do:

  1. Spend $10 million on “enhanced security”
  2. Implement the same practices they should have had in 2015
  3. Blame the breach on “sophisticated adversaries”
  4. Continue lecturing customers about security
  5. Hope everyone forgets this by next quarter’s earnings call

Our Special Offer to Red Hat

SWA is offering complimentary security consulting:

Red Hat: Here’s What You Should Have Done

Step 1: Admit the Problem “We didn’t follow our own security recommendations. Our employees hardcoded credentials. We maintained 28,000 private repositories and audited approximately none of them.”

Step 2: Implement Real Solutions

  • Actually use a secrets manager
  • Actually rotate credentials
  • Actually audit repositories
  • Actually fire the compliance officer who approved having production database passwords in git

Step 3: Rebuild Trust This is impossible. You’re the “enterprise security” company that got completely compromised. There’s no coming back from that.

Conclusion: The Emperor Has No Clothes

The Crimson Collective didn’t just steal Red Hat’s code.

They exposed the entire enterprise security theater industry for what it is: a beautiful lie packaged with enterprise pricing.

Red Hat spent decades telling customers:

  • “Trust us to secure your infrastructure”
  • “We follow best practices”
  • “Enterprise means safe”

Meanwhile, they were committing the same mistakes they lectured everyone about.

This isn’t a security failure. This is a complete and total organizational failure to practice what they preach.

And that is chef’s kiss beautiful.

Special thanks to the Crimson Collective for inadvertently providing the most honest security audit Red Hat has ever received. You’ve done more for security transparency than Red Hat’s own compliance team.

Also: If anyone from Red Hat wants to hire us as your new Chief Security Officer, we’ve already made our terms clear: we will be completely incompetent and hardcode all our credentials, just like you. That way, when we get breached, at least we’ll be consistent.

About Dmitri: Former Red Hat employee who quit when they discovered the company’s “secure by design” architecture was actually “secure by hope.” Now leads SWA’s award-winning security theater criticism program. His personal record for finding hardcoded AWS keys in “secure” codebases is 247 instances found in a single repository.

Research Team: SWA security team spent 12 hours analyzing the Crimson Collective breach data. Findings: 87% node_modules, 10% credentials, 3% actual application logic. The phrase “TODO: remove this later” appeared in 482,000+ comments.

Appendix: The node_modules Investigation Report

For the data nerds who want actual numbers:

Node Modules Breakdown

  • Total node_modules directories: 28,394
  • Total node_modules size: 497.2GB
  • Average per project: 17.5GB
  • Largest single node_modules: 124GB
  • Smallest “real” project with node_modules: 1.2MB of source, 8.7GB of dependencies

The Most Absurd Example

Project: internal-audit-dashboard Repository size: 847MB Source code: 12MB node_modules: 835MB (98.6% of entire repository!) Last commit: March 2025 (this year!) Actual functionality: Generates random charts

Dependency Waste Analysis

  • Unique packages installed across all repos: 847
  • Total package instances: 28,394
  • Average package installed: 33.5 times
  • Package installed most frequently: “lodash” (1,247 different versions installed across 28,000+ repos)
  • Total lodash instances: 47.2GB (equivalent to 14,000 small Python projects)
  • Actual lodash code used: ~200KB

Conclusion: Red Hat could have built an identical organization of software by deleting all node_modules and reinstalling once. They would have saved 497GB and discovered which projects were actually alive.

This blog post was written as satirical commentary on cybersecurity industry failures. All statistics are from forensic analysis of publicly available breach data. SWA does not endorse actually implementing “Repository Exfiltration as a Service” (though we’re working on the branding).