Red Hat GitLab Breach: When Consulting Artifacts Become Attack Blueprints

October 2025. A threat group calling itself Crimson Collective claims responsibility for one of the year’s most consequential breaches. Their target: Red Hat’s internal GitLab instance. Their haul: 570GB of compressed data from over 28,000 repositories.

But the headline number understates the impact. Among the stolen data were 800 Customer Engagement Reports (CERs)—documents created during Red Hat consulting projects for enterprise clients.

What Was Exposed

Customer Engagement Reports aren’t marketing materials. They’re technical documents containing:

• VPN configurations and network diagrams
• API keys and authentication tokens
• Infrastructure configuration data
• Credential sets for production environments
• Access procedures for client systems

The client list included some of the world’s largest organizations: IBM, American Express, Cisco, the NSA, and the Department of Defense. Each CER represented a potential roadmap for attacking that client’s infrastructure.

This wasn’t just a Red Hat problem. It was a supply chain breach that turned consulting deliverables into reconnaissance packages for attackers.

The Static Credential Problem

At the core of this breach is a familiar anti-pattern: static credentials in documentation.

When consultants deploy systems, troubleshoot issues, or document configurations, credentials often end up in reports, runbooks, and code repositories. Sometimes intentionally (for reference), sometimes accidentally (copy-paste errors). Rarely are they rotated after the engagement ends.

These credentials have long half-lives. A VPN key created for a 2023 engagement might still work in 2025. An API token generated for testing might have been promoted to production. A service account password might be the same one used across multiple environments.

Attackers know this. Stolen consulting documents aren’t just intelligence—they’re operational access.

Downstream Risk Calculation

If your organization was a Red Hat consulting customer, the breach creates immediate questions:

1. Were we included in the stolen CERs? Red Hat’s breach notification should clarify, but organizations should proactively reach out.

2. What credentials were documented? Review your own records of what was shared with or created by Red Hat consultants.

3. Are those credentials still valid? If any credential from a consulting engagement hasn’t been rotated since, rotate it now.

4. What infrastructure was documented? Network diagrams and VPN configs provide targeting information even without valid credentials.

Even if credentials have been changed, the architectural knowledge in those documents has value to attackers. Understanding network topology, security tool placement, and access patterns enables more sophisticated attacks.

Beyond This Breach: Consulting Hygiene

The Red Hat incident highlights a broader problem: organizations don’t consistently track what consultants know about their infrastructure.

Best practices for managing consultant risk:

Credential isolation. Create dedicated accounts for consultants with minimal necessary access. Disable them immediately when engagements end.

Avoid static credentials in deliverables. If documentation must reference credentials, use placeholder values. Store actual credentials in secrets management systems with access logging.

Secret scanning. Implement automated scanning for credentials in code repositories, documents, and collaboration tools. Tools like GitLeaks, TruffleHog, and vendor-native solutions catch accidental exposure before it becomes permanent.

Engagement offboarding. Treat consultant departures like employee offboarding. Audit what they accessed, rotate shared credentials, revoke persistent access.

Vendor security requirements. Require consultants to meet specific security standards for handling client data. Ask: How long do you retain engagement artifacts? How are they protected? Who has access?

Checklist: Post-Breach Review

• Determine if your organization was a Red Hat consulting customer in the relevant timeframe
• Inventory credentials and configurations shared with or created by Red Hat consultants
• Rotate any credentials that may have been included in engagement documents
• Review VPN and remote access configurations documented in past engagements
• Implement automated secret scanning in all code repositories
• Audit current consultant access and credential sharing practices
• Update vendor security requirements to address engagement artifact retention

The Bigger Picture

This breach underscores an uncomfortable truth: your security perimeter extends to every vendor who has touched your systems. Their security failures become your exposure.

Red Hat is a sophisticated technology company with mature security practices. If their internal repositories can be compromised, any vendor’s can. The question isn’t whether to trust vendors—it’s how to limit the blast radius when that trust is violated.

Static credentials are time bombs. The Red Hat breach just lit a lot of fuses.

---

At Dédalo, we help organizations audit their repositories for exposed secrets and implement secure credential management practices. Need to assess your exposure? Let’s talk.