In October 2025, an extortion group calling itself Crimson Collective announced it had breached a GitLab instance operated by Red Hat's consulting division. The group claimed to have exfiltrated approximately 570 gigabytes of data across roughly 28,000 internal repositories. Red Hat confirmed the breach on October 2, describing the compromised data as consulting engagement material including project specifications, code snippets, internal communications, and limited business contact information.
GitLab confirmed separately that the affected instance was Red Hat's own self-managed GitLab Community Edition deployment — a self-hosted environment for which Red Hat was responsible for security configuration, patching, and access controls. GitLab's own infrastructure was unaffected.
Crimson Collective's claimed scope has not been independently verified. What is confirmed: within 48 hours, the group partnered with ShinyHunters — an established extortion-as-a-service operation taking 25 to 30 percent of revenue in exchange for infrastructure and distribution — and published data samples on their leak site. On October 10, the FBI, U.S. Department of Justice, France's BL2C cybercrime unit, and the Paris Prosecutor's Office seized BreachForums, the primary distribution platform, disrupting the planned public release.
The downstream impact materialised two months later. In December 2025, Nissan Motor disclosed that approximately 21,000 customers from its Nissan Fukuoka Sales subsidiary had been exposed. Red Hat had been commissioned by Nissan to develop customer management systems. The compromised data included names, addresses, phone numbers, and email addresses. Red Hat notified Nissan after identifying them as an affected client. Nissan's public disclosure came three months after the initial breach.
One consulting firm's internal repository. A confirmed downstream victim with 21,000 real customer records. A three-month notification lag.
One internal environment. One breach. The client portfolio in the exposure window.
The structural difference
When an organisation engages a consulting firm for a technical project — IT implementation, digital transformation, platform development — that firm needs working access to do its work. API keys, database credentials, authentication tokens, network configuration files. These get copied into the firm's working environment: their internal repository, their project management platform, their communication channels.
Individually, each engagement looks manageable. One client, one project folder, one set of credentials in a defined scope.
Consulting firms do not have one client. They have dozens or hundreds. Their internal systems are aggregation environments — a single GitLab instance, a single Confluence space — where credentials and engagement data from all active and historical projects accumulate over time. A threat actor that breaches a consulting firm's internal environment is not targeting one organisation. They are targeting the entire client portfolio at once.
Crimson Collective, a group that had existed for approximately one week before the Red Hat breach, extracted consulting engagement data from what Red Hat describes as a platform used for collaboration "in select engagements." The breadth of that data — and which clients were in scope — was determined not by Crimson Collective's sophistication, but by the architecture of Red Hat's internal repository.
The data behind the problem
GitGuardian's State of Secrets Sprawl 2026 report examined 13 consulting firms appearing in its monitoring dataset. Those 13 firms generated 1,834 secrets classified as critical or highly sensitive — an average of 141 sensitive incidents per firm. The 1,203 companies potentially affected by those leaks came through just 13 organisations. The top five firms accounted for 72 percent of all incidents.
Internal repositories are six times more likely to contain hardcoded secrets than public ones — 32.2 percent of internal repos contain at least one hardcoded credential, compared to 5.6 percent of public repositories. Development teams working inside a trusted perimeter treat credential hygiene differently. Secrets get committed temporarily. Configuration files with live database URIs get checked in because the deployment requires them. The assumption is that access controls will contain the exposure.
At Red Hat's consulting GitLab instance, access controls did not contain it.
A further 28 percent of credential incidents originate entirely outside the codebase — in Slack messages, Jira tickets, Confluence pages. Incidents originating from these collaboration tools are 13 percentage points more likely to be rated critical than those found in source code. Consulting firms use all of these tools across all client environments, with no natural isolation between them.
The pattern is not specific to GitLab
Red Hat's self-managed GitLab instance is one example. The underlying flaw appears across different vendor types.
ShinyHunters' current victim list — the same group that partnered with Crimson Collective on the Red Hat extortion — includes multiple companies described as breached via Anodot, an analytics and business intelligence vendor. Vimeo, Zara, and Rockstar Games all appear with the notation that their Snowflake or BigQuery instances were "compromised thanks to Anodot.com." An analytics vendor held cloud data access for multiple clients. Their environment was compromised. Their clients' data followed.
CFGI Management, a financial consulting firm, also appears on the same list — 800,000 records and over 40,000 financial documents. A consulting firm as victim rather than vector, but the underlying dynamic is identical: one environment, concentrated client data, one point of failure.
Whether it is a GitLab instance running client project code, a business intelligence vendor holding Snowflake credentials, or a financial firm managing client documents — the exposure geometry is the same. Third-party vendors accumulate client access as a function of how the work is done. That accumulation makes them targets.
If your organisation uses consulting firms, IT contractors, or managed service providers with access to production systems or internal credentials, a Corporate Audit maps the third-party exposure surface you may not be able to see from inside.
Talk to an AnalystThe persistence factor
The exposure does not end when a project does.
GitGuardian's 2026 report re-tested credentials from their 2022 monitoring dataset in January 2026 and found that 64 percent of those secrets remained valid — four years after they first appeared in a repository. Of credentials from 2025, only 23 percent had been rotated by the time of retesting.
When a consulting engagement closes, the firm's repository history is typically archived rather than deleted. Git retains every commit. A credential embedded in a configuration file in 2022 survives in that history unless someone explicitly rewrites it — a process requiring identification of every occurrence across every branch, coordination with every downstream system, and disruption of whatever the credential currently powers. Most teams choose not to do this. The credential persists.
A consulting firm that has run hundreds of engagements carries, in its repository and collaboration tool history, credentials from clients who have long since moved on. Some remain valid. When that firm's environment is breached, those historical credentials re-enter the exposure window alongside the current ones.
The Shai-Hulud 2 supply chain campaign, which harvested credentials from developer machines by compromising npm packages, found that each live credential appeared in an average of eight different locations on the same machine: dotfiles, shell profiles, build outputs, IDE configurations, tool caches. Inside a consulting firm's shared environment, a credential committed once propagates across branches, container images, and archived project folders over the life of the engagement — and beyond it.
What to ask before granting access
Most vendor questionnaires cover certification status, data handling policy, and incident response procedures. They rarely address where client credentials specifically reside inside the firm's internal environment, or what happens to them when an engagement ends.
Red Hat answered those questions empirically: engagement data from a confirmed Nissan project sat in a self-managed GitLab CE instance — infrastructure Red Hat was responsible for patching and securing — and was accessed by a week-old extortion group. Three months passed before Nissan's 21,000 customers were notified.
Before granting a consulting firm elevated access to production systems, development infrastructure, or internal API keys, the following questions establish whether the firm has addressed the aggregation problem it creates:
- Where specifically are our credentials stored in your internal environment, and how are they isolated from other client credentials?
- What is your credential decommissioning policy at project close — are they actively rotated, or archived?
- Do you operate isolated per-client environments or a shared development infrastructure?
- Who has access to the repositories where our project is developed, beyond the immediate project team?
- Has your internal development environment undergone an independent security assessment in the past twelve months?
- How would you notify us if your internal systems were breached and our credentials were in scope?
For organisations whose consulting relationships involve elevated access — cloud IAM tokens, production database credentials, network configuration — a standard vendor questionnaire is not a sufficient basis for that trust. The credential and engagement data created by those relationships warrants an independent assessment before access is granted.