Red Hat has confirmed a security incident involving a GitLab instance used by its Consulting division after a hacker group called “Crimson Collective” claimed to have exfiltrated roughly 570 GB of compressed data spanning 28,000 internal repositories, including some 800 Customer Engagement Reports (CERs) that may contain infrastructure-level details like network configurations, credentials, and database URIs. Red Hat insists that the breach was isolated to its consulting business and that its software supply chain and core products remain uncompromised, but it is continuing to investigate. Meanwhile, the attackers published a directory listing and named many high-profile organizations as allegedly affected, and attempted an extortion demand that Red Hat reportedly ignored beyond a templated response.
Sources: Bleeping Computer, Security Week
Key Takeaways
– The breach impacts one of Red Hat’s self-managed GitLab instances used by its consulting arm, not its publicly managed software offerings or supply chain.
– The data allegedly stolen includes client consulting reports (CERs) that may disclose system blueprints, secrets, and infrastructure details—elements that could be leveraged in further attacks.
– Red Hat claims to have contained the breach, initiated remediation, and is notifying potentially affected clients, but uncertainty remains over initial access and full scope of exposure.
In-Depth
In what may become one of the more consequential consulting-sector breaches of 2025, Red Hat has confirmed unauthorized access to a GitLab instance used by its consulting division, after a group calling itself the Crimson Collective claimed to have stolen about 570 GB of compressed data from 28,000 internal repositories. The attackers say the haul includes some 800 Customer Engagement Reports (CERs)—documents that in many cases contain internal infrastructure blueprints, authentication tokens, database URIs, VPN configurations, and other sensitive data about client systems.
Red Hat clarified that the compromised environment was entirely separate from its mainstream product development infrastructure; the breach was limited to the GitLab instance used for internal consulting project collaboration, not its upstream open source code or distribution systems. The company asserts that its software supply chain and general services remain unaffected. To respond, Red Hat says it removed the attackers’ access, isolated the instance, launched a forensic investigation, and is working directly with customers who may have been impacted.
That said, the scope of the attack raises serious concerns. The leaked directory listings published by Crimson Collective name many high-profile clients, spanning sectors from banking to government. The possible exposure of architectural diagrams, token secrets, and system configurations could enable follow-on attacks or lateral movement into client networks. Analysts point out that the presence of such data in a repository environment underscores a perennial problem in enterprise security: insufficient separation and overexposure of secrets within development or shared collaboration environments.
The question of how the attackers initially gained access is still unanswered. Some speculate that token mismanagement, weak access controls, or incomplete patching on the GitLab instance may have enabled the intrusion. Red Hat has not confirmed the root cause, and investigations are ongoing. The attack also highlights the challenge for firms that rely heavily on third-party or consulting infrastructures: even if your core systems are secure, a breach in a consulting or auxiliary environment can cascade into your critical assets.
Clients tied to Red Hat Consulting should proactively rotate credentials, audit any integrations or tokens issued, review logs for suspicious activity, and coordinate closely with Red Hat as the investigation unfolds. Meanwhile, the broader industry must take this incident as a warning about how deeply sensitive operational data is now shared—and potentially exposed—through development tooling.