Red Hat Consulting — Crimson Collective repository theft

On 1 October 2025 a previously little-known cybercrime group calling itself the Crimson Collective publicly claimed to have exfiltrated 570 GB of compressed data from over 28,000 repositories on a private GitLab instance operated by Red Hat. Red Hat published a brief security update the following day, confirming that the affected GitLab tenant was used “solely for Red Hat Consulting on consulting engagements” and was separate from any infrastructure supporting Red Hat Enterprise Linux, OpenShift, Ansible or any other shipped product. On 10 October 2025 the Financial Industry Regulatory Authority issued a member-firm cybersecurity alert specifically about the incident, on the basis that named European and US banks featured in the disclosed data.

The dataset is the part to dwell on. Red Hat Consulting is not a generalist services arm. Its work consists of long, technically deep engagements with very large enterprise and public-sector customers, building internal infrastructure on Red Hat platforms and tuning it for production. The artefacts those engagements produce — and which the consultants stored in the affected GitLab tenant — are operational blueprints. Crimson Collective’s claim, supported by partial samples published as proof, was that the haul included roughly 800 Customer Engagement Reports spanning 2020 to 2025. The CER format, as documented by GitGuardian and Anomali in their post-incident analyses of the leaked samples, typically includes infrastructure topology diagrams, internal network segmentation maps, security-control assessments, vulnerability findings against the customer’s environment, authentication tokens, API keys, database connection strings, CI/CD pipeline configurations, VPN profiles, Ansible playbooks and OpenShift cluster install blueprints. The customer list named in the leaked samples included IBM, American Express, Cisco, the National Security Agency, the United States Department of Defense, and a number of named European banks.

The intrusion mechanism is the part the public record is thinnest on. Red Hat’s official statement confirmed unauthorised access to the GitLab tenant, immediate revocation of the attacker’s access, isolation of the affected instance, and engagement with appropriate authorities, but did not disclose how Crimson Collective gained initial access. The post-incident analyses from GitGuardian, Anomali and Cybernews all note this gap and decline to speculate. The most that can be said with confidence is that the affected tenant was a self-managed GitLab Community Edition instance — not a SaaS GitLab.com tenant — operated for internal Consulting collaboration only, and that the access route either chained through stolen consultant credentials or exploited a self-managed-edition vulnerability. Red Hat has made no statement on which.

The downstream impact pattern is unusual, and worth recording. Red Hat itself has limited direct exposure: no shipped-product code, no customer-facing service infrastructure, no end-user authentication system was touched. The impact lives almost entirely in the customers named in the engagement reports. Each affected customer now has to assume that an attacker holds, for some defined period of their relationship with Red Hat Consulting, an accurate internal-network blueprint, working credentials, and a list of identified vulnerabilities the consulting team flagged but the customer may not yet have remediated. The defensive workload sits with each named organisation separately, and the cost falls disproportionately on those that didn’t move quickly enough on the original CER recommendations.

Crimson Collective itself is the third notable feature. The group did not previously have a public profile. Its tactics — public claim, sample-data drop, broad media outreach — are closer to the LockBit / ShinyHunters extortion playbook than to the quieter exfiltrate-and-trade pattern of state-aligned data-theft groups. There is no public attribution to a state, and no analyst report so far has placed Crimson Collective inside an existing tracked cluster. Whether the group is a new brand for an existing actor, or genuinely new, is still open at the time of writing.

The defender takeaway is unfamiliar to most security programmes, because the asset class — a vendor’s consulting-engagement notes about your infrastructure — is not one most third-party-risk frameworks treat as material. Most professional-services contracts include a confidentiality clause and a data-handling addendum, and stop there. The Red Hat case is an argument for treating consulting-engagement deliverables as a critical-third-party data category in their own right: scoped data-handling agreements, deliverable-level encryption-at-rest with customer-held keys, retention limits beyond engagement closure, and an audit-of-storage clause. The customer-side mitigations are equally unromantic — rotate any credentials shared with the consulting team during the engagement window, treat documented network topology as a known disclosed item rather than a confidential asset, and prioritise remediation of any CER findings that are still open. The attacker now has the homework. Make sure the homework is no longer current.