Three 2026 Leaks, Opened and Read: What Disney, S&P Global's CI Pipelines and ZenBusiness Really Contain

Category: breach reports · Source: HIBR leak analytics (/api/fullmetadata/<id_source>) for leaks aa1757ef9cb9, 28244 and 27578, plus record-level reading of the leak content.

A leak has a name, and the name sets an expectation. "Disney internal Slack" sounds like chat logs. "LiteLLM" sounds like an AI library. "ZenBusiness" sounds like a customer list. Because we hold the full content of these leaks, we can open them and read each record in context. In all three cases, the label and the content only partly match, and the gap is the story.

Read this as three cases side by side. The claims about who leaked what are the publishers' and attackers' claims; we have not verified any of them.

The short answer

These scores are estimates from a written rubric (methodology v2.0, explained in each section), not probabilities and not formal attributions. The records without an email are not empty. They hold other data, such as names, identifiers, internal fields and secrets. Email is simply the easiest thing to count, so "% with email" understates how much personal or sensitive data each leak holds. We have not quantified the non-email types, so we give no percentages for them.

How to read the percentages

Every percentage names its base. "Corporate" and "Personal" are HIBR's two email classes, and the shares in the top-5 tables are within that class, not of all emails. "Records read in context" means the records returned for the domain named, up to 1,000, read one by one; they describe those records and are never extrapolated to the whole leak.

What "Corporate" and "Personal" mean. Personal is an address on a fixed list of free-webmail providers. Corporate is everything else. So "corporate" does not mean "belongs to the victim": third-party companies, mail relays, service accounts and unlisted webmail all land there. We verified this rule in the deployed code during the earlier European Commission analysis (DARA-948).

1 · Disney internal Slack (aa1757ef9cb9)

What the label says. The leak is titled "Disney internal Slack", with a description of Disney and Hulu internal communications. It is indexed as a traditional breach (leak_type), with a post on ddosecrets.org. DDoSecrets is a collective that publishes leaked data; it is not a ransomware group. This is its April 2026 republication of the leak that NullBulge published in 2024. The HIBR label ddosecret and the earlier wording of this post could be read as a ransomware listing (see the correction at the end).

What we found inside.

By file type (share of records counted per type): 71.4% CSV, 19.8% JSON, 5.0% XLS, 2.4% XLSX, 1.1% PDF, 0.2% legacy DOC, 0.1% databases. Mail archives are marginal (.eml, under 0.01%) and there are no .mbox files. The type counts add up to 6.8% more than the leak's record total, so treat them as approximate. This is a tabular dump far more than a chat export.

Reading records in context (1,000 per domain):

• disney.com records: 76.3% carry employee-record fields (employee ID, hire date, seniority, work-state descriptions, start/stop times). That looks like workforce-scheduling data. A further 10.3% carry IT access or configuration fields.
• hulu.com records: 96.5% are access-permission rows (user ID, application ID, enterprise account ID, permission level).
• gmail.com records: 65.8% are HR-style person profiles (nationality, gender, position, assignment dates), and 33.7% are the same permission rows as above.
• The word "Slack" appears in 1.8% of disney.com records and 1.9% of hulu.com records, and in none of the gmail ones.

This does not prove there is no Slack content: our reading is driven by email domains, and the JSON share (19.8%) could hold exports we did not reach. What we can say is that the records we read are overwhelmingly HR, access-control and risk-register data, not conversations.

Corporate vs Personal. 32.2% of emails are Corporate and 67.8% are Personal, of 9,442,051 addresses.

Reclassified against all addresses: Disney-family domains (disney.com, hulu.com, disneystreaming.com, abc.com, espn.com, test.disney.com, email.disney.com) are at least 23.4% of all emails (a floor, since only the top-10 corporate domains are published). Gmail alone is 40.5% of all emails. Corporate also includes a mail-delivery relay (SparkPost) and an ISP address (cox.net), which shows why the label is loose.

Countries · identity documents. Only 2,196 records are identity documents, so this base is small. Top 5 (% of identity documents, using the country field attached to each document record; we could not read the extraction logic):

Nearly nine in ten documents have no country, so we draw no geographic conclusion. (GB and UK are separate labels for the same country in the source.) The TLD-inferred country view is omitted: the published domains are overwhelmingly generic .com.

Does the content match the victim? 72/100 (methodology v2.0 estimate). The 2024 incident is confirmed: a US Department of Justice release on the guilty plea of the person who took Disney's Slack data. The dataset itself is only partly verified. Employee tables and Hulu permission data are there, but Slack-message markers appear in only about 1.8% of the records we read, and we could not compare files against the original archive. Disney domains are 22.5% of distinct corporate addresses (a lower bound) and the most frequent corporate domain; 14.5% of records come from source files whose path contains the organisation name. The largest third party is a mail relay (20.6% of distinct corporate addresses), which counts for nothing against Disney. The Disney domains were inferred from the post title, not declared. A verified Disney statement or filing would raise the estimate further; we did not count one we had not opened.

2 · The "LiteLLM" leak, actually filed under S&P Global (28244)

What the label says. The leak is listed by Vect against S&P Global, tagged "LiteLLM/Trivy campaign (TeamPCP)", with "internal projects, secrets, API keys", 250 GB and a negotiation deadline (the group's claim). The title already hints at something wider than one victim.

What we found inside.

By file type: 64.5% database-type records and 35.5% text records. Every one of the 2,255 records we read carries a path starting with suppluchain/: the content is automated reports, one per CI/CD runner, each listing the runner's host, user, environment and the secrets found. This is not a document dump.

Reading records in context:

How this compares with what you would expect: GitHub and GitLab credentials are plentiful, and private SSH keys appear in a large share of the records. The environment data are captured as counts and variable lists from runners, not as .env files. GPG material appears in only 2.3–2.8% of records and only by keyword, so we cannot confirm it as private keys. In the records we read, every one of the 606 secrets of the SSH-key, GitHub-token and AWS-key-ID types is shown truncated, not in full. We did not check all records.

The twist: S&P Global is a small slice. Only 544 of the 204,612 records (0.27%) match spglobal.com, and all of them trace back to a single address, a GitHub Actions pipeline labelled with an S&P "innersource" organisation. Meanwhile the GitHub-matched records alone span 78 distinct company labels and the GitLab-matched ones 21. The content reads as a harvest across many organisations' pipelines, consistent with the "campaign" wording in the title, with S&P Global as one of them.

Corporate vs Personal. 97.0% Corporate and 3.0% Personal, of 155,672 addresses. 57.9% of records have an email, and some have more than one.

The Corporate class includes a cloud service account and an invalid value, so it is not a list of companies. Our hypothesis, from the commit-author and actor fields in the records read, is that these addresses are the Git identities of developers who triggered the pipelines, not mailbox contents. No country data exists for this leak, so no geography section is included.

Does the content match the announced victim? 39/100 for S&P Global as owner; 83/100 for the campaign (methodology v2.0 estimates). These are two different questions, so we score both. The TeamPCP campaign (Trivy, then LiteLLM, March 2026) is confirmed by several independent security vendors, and the records carry the artefacts they describe, so the dataset-belongs-to-the-campaign estimate is 83; it is the estimate for the campaign, not for S&P Global. What is missing is a file-level comparison. This is a multi-victim dataset: only 544 records (0.27%) are relevant to S&P Global. S&P Global has not confirmed it; the S&P-specific sources are a single vendor and a brief that says "unconfirmed by third parties". So "this is S&P Global's leak" scores 39, with S&P material demonstrably inside it. Distinct spglobal.com addresses are 0.04% of distinct corporate addresses. This is a statement about the content, not about S&P Global's security, and it does not say S&P Global was unaffected.

3 · ZenBusiness (27578)

What the label says. ShinyHunters lists ZenBusiness, Inc. and claims "several terabytes" from Snowflake, Mixpanel and Salesforce, with a final-warning deadline (the group's claim).

What we found inside.

By file type: 99.15% CSV and 0.85% legacy DOC. The type counts exceed the leak's record total by exactly the DOC count, so the total may exclude DOC records. This is the largest of the three leaks, at 2.8 billion records.

Reading records in context (1,000 per domain):

• zenbusiness.com records: 100% carry Fivetran sync columns, meaning these are warehouse tables replicated by Fivetran. 77.0% are CRM-style email-to-record link tables, 12.1% are logs of LLM interactions (prompt IDs, model name, token counts, latency, response), and 6.6% are issue-tracker rows.
• gmail.com records: 99.8% carry Fivetran columns. 50.0% are product access-audit events (event type, actor type, operation, business-entity ID), and 33.9% are contact-status rows (hard-bounce, unsubscribed, marked-as-spam flags, country, browser language).
• A phone or CRM trace: "phone" appears in 10.9% of the gmail records and "Salesforce" in 30.7%. The leak has contact details attached to emails, which is the kind of data that lets a customer find their own record.

The pattern fits the group's own list of sources: warehouse exports, not mailboxes. It also exposes something the headline does not: LLM interaction logs in the same dump.

Corporate vs Personal. 24.3% Corporate and 75.7% Personal, of 454,364,504 addresses (16.1% of records have an email).

Reclassified against all addresses: zenbusiness.com is 9.6% of all emails, and gmail.com alone is 58.6%. Two of the five corporate domains are US state business registries and one is a registered-agent company. Hypothesis: a business-formation service naturally exchanges email with Secretary of State offices and registered agents. The domains show who the data talks about, not how anyone got in.

Does the content match the victim? 61/100 (methodology v2.0 estimate). ZenBusiness addresses are 7.0% of distinct corporate addresses (59,311 distinct zenbusiness.com addresses), and the Fivetran and CRM markers fit the claimed Snowflake, Mixpanel and Salesforce sources. But those structures are generic: they show the source system, not that only ZenBusiness could hold them. ZenBusiness has not confirmed publicly. Have I Been Pwned lists about 5 million addresses for the incident, an independent sign it happened. The transactional mail relay (Mandrill) no longer counts against the estimate, because a relay says nothing about whose data it is. What would raise it: a company statement or regulator filing, a count comparison with the HIBP figure, and a second independent technical report. One mismatch is open: sources say "thousands of files", HIBR lists 638.

What the three have in common

Fact: none of the three is what its label suggests at first read. One is HR and access-control data under a "Slack" title; one is credentials harvested from many organisations' build pipelines under a single company's name; one is a data warehouse that includes AI logs.

Hypothesis: the label usually comes from the victim list, the attacker's note or the publisher's headline, while the content comes from whichever system was reached. Reading the records is the only way to see the difference.

What none of it shows: how anyone got in. A domain, a pipeline label or a table name is not an entry point.

Why it matters

For defenders, the unit of exposure is not "an email count". It is "which kind of data, for how many distinct people or systems". A CI-secrets harvest means rotating credentials across every organisation named in it; an HR and access dump means insider-risk and identity fraud; a customer warehouse means phishing and notification duty.

You can check whether a domain of yours appears in indexed ransomware leaks at HaveIBeenRansom.

Update and correction, 5 October 2026. (1) We recalculated the attribution-confidence estimates with methodology v2.0, which applies one rubric to every leak: the organisation's email domain weighs less, third-party mail relays and cloud hosts are no longer penalised, and outside corroboration is scored separately for "incident confirmed" and "dataset verified". Changes: Disney 54 to 72; S&P Global 6 to 39, plus a new 83 for the LiteLLM/TeamPCP campaign; ZenBusiness 26 to 61. All are estimates and carry ±5 of analyst judgement. (2) Correction: an earlier version of this post, following the HIBR label ddosecret and its API description, treated DDoSecrets as a ransomware-style listing. DDoSecrets (ddosecrets.org) is a leak-publishing collective; the Disney dataset is its April 2026 republication of the 2024 NullBulge leak. It is not a ransomware group.