A new cybercrime group claims it hacked into Red Hat’s private GitLab repositories and stole some of the company’s most sensitive data, disclosing the theft to BleepingComputer to prove its claim, and causing concern over what customer information might be exposed after problems with a previous leak dumped sensitive consulting files on the internet. Red Hat has confirmed unauthorized access to a self-managed GitLab instance utilized by its Consulting team, and continues to investigate.
Who broke into Red Hat’s GitLab, and what was taken
The trespassers identify themselves as Crimson Collective or Eye of Providence. They also made publicly available screenshots to confirm their allegations, stating that they pilfered hundreds of gigabytes of content from tens of thousands of internal repositories, including around 800 Customer Engagement Reports (CERs). These figures remain unverified.
- Who broke into Red Hat’s GitLab, and what was taken
- Which Red Hat Consulting customers may be exposed
- What this breach means for risk and exposure
- What organizations affected in the immediate term should do
- What we still don’t know about the Red Hat GitLab breach
- The bottom line for Red Hat customers after the breach
The break-in was confined to a GitLab Community Edition instance limited to supporting specific consulting engagements, according to Red Hat. A company spokesman told the news service that the unauthorized access was taken offline, the system was isolated and authorities were alerted. Red Hat maintains that “generally no sensitive personal data” is found in this space and, as of right now, its initial investigation has not indicated anything concerning malicious access to said data.
GitLab, for its part, says that its managed services and infrastructure remain unaffected; and that the incident concerns a self-hosted deployment — meaning a user-managed instance of GitLab’s software which they themselves host — in which case the customer who owns the installation is responsible for it (not GitLab).
Which Red Hat Consulting customers may be exposed
Crimson Collective says it owns CERs associated with leading private-sector companies and U.S. government organizations. Those details have not been publicly confirmed by Red Hat. The breach affects only Red Hat Consulting customers, the company says, and there is no evidence indicating the compromise has any relationship to other Red Hat products, services or software distribution network.
CERs can be sensitive since they frequently contain details of client architectures, network topologies, and configuration notes. Some may even contain authentication tokens or example credentials on how to connect.
If any of that content is accurate and up-to-the-minute, it could help attackers plot attacks or a path for moving laterally against those downstream environments.
What this breach means for risk and exposure
Red Hat’s products and services are fundamentally open source so the mere availability of code is not the primary risk. The larger issue is operational detail: diagrams, deployment layouts, integration instructions and embedded secrets. Even scraps of internal communications, if any are available, can provide insight into how systems are maintained and where gaps might exist.
Cited tokens, keys or temporary credentials should be considered potentially compromised by security teams. Verizon’s Data Breach Investigations Report has regularly called out credential misuse and social engineering as the most dominant vectors, while exposed secrets in developer tooling remain one of the top contributors to real-world incidents. If Crimson Collective’s assertions about CER access are true, opportunistic pivoting is probably the path of least resistance.
What organizations affected in the immediate term should do
- Ask your Red Hat account team if your organization’s consulting engagement data was included in scope and request a list of any files that could contain references to your environment.
- Consider CER contents as suspect pending further verification.
- Rotate any credential that can reasonably be leaked: API keys, service accounts, SSH keys, personal access tokens, or any credentials documented or specified in examples. Re-issue secrets from a centralized secrets manager with short-lived lifetimes.
- Harden identity and access controls. Require MFA for all admin access, reduce role-based access control to a least-access approach, and implement conditional access or network allowlists around your sensitive interfaces like Git, CI/CD, Kubernetes, and cloud management consoles.
- Increase detection coverage. Check logs for out-of-the-ordinary authentication patterns, repo clones at scale, unexpected CI/CD pipeline execution, or outbound connections from build systems. Develop a bowtie by mapping potential attacker TTPs to MITRE ATT&CK techniques to focus hunting.
- Scrub code and documentation with automated scanners for secrets, and use pre-commit hooks to prevent reintroducing secrets. If you run self-managed Git services, install the latest patches, check access tokens, and disable unnecessary integrations.
What we still don’t know about the Red Hat GitLab breach
Key details remain unsettled. The specific amount of data being copied, the truth behind how much the attackers have not released, and if any stolen content will be posted to leak sites is not known. So far, there are no verified source code or CER dumps that have been found by reliable leak trackers and Red Hat’s investigation is still ongoing.
No one could verify whether the credentials referred to in any consulting materials were current, time-limited or sterilized. That difference would be relevant to practical risk for the customers identified in any records.
The bottom line for Red Hat customers after the breach
The incident seems to be contained within a consulting GitLab instance, but consulting artifacts can make for rich targets. If you engaged Red Hat Consulting, consider yourself at risk until you have definitive scoping provided by Red Hat and carry out your own containment measures. If you did not, Red Hat says there is no indication that other services or product supply chains were affected.
Even if you’re not directly impacted, consider this a reminder to shrink the blast radius of developer platforms: store secrets outside repos, rotate tokens aggressively, compartmentalize CI/CD, and continually watch for anomalous access. Those acts are far more significant than whether the underlying code was open or closed.