2026-07-19 · view entry permalink →
Ernst & Young discloses a breach of a third-party IT support-ticket platform used by its tax practice, exposing client tax and financial documents
Ernst & Young LLP (EY), one of the "Big Four" audit/tax/consulting networks, filed data-breach notifications with the California and Vermont Attorneys General on 2026-07-15 after determining that an unauthorized third party had accessed a third-party IT service-management (ITSM) platform used by its tax practice (California OAG, 2026-07-15). EY detected anomalous activity on 2026-04-23 and an external forensics firm concluded that the intruder had access "between March 28 and April 12 and downloaded multiple documents" belonging to multiple tax clients, a roughly two-week access window, detected about eleven days after the intruder's access ended (BleepingComputer, 2026-07-17). The platform manages IT support tickets for tax-engagement work, and "support tickets submitted through the platform may include documents containing client tax information", the financial information used to prepare tax filings (CyberInsider, 2026-07-17); the regulatory notice letter itself redacts the specific data elements involved. EY has not disclosed the initial-access vector, named the compromised third-party platform, stated how many individuals are affected, or said whether non-US clients are impacted; no extortion or ransomware group has claimed the intrusion, and EY is offering 24 months of identity monitoring to affected individuals (BleepingComputer, 2026-07-17).
an unauthorized third party had accessed the said platform between March 28 and April 12 and downloaded multiple documents
Support tickets submitted through the platform may include documents containing client tax information.
Sample of Notice: EY Notice Letter US General.pdf Organization Name: Ernst & Young LLP Date(s) of Breach (if known): Saturday, March 28, 2026 Thursday, April 23, 2026
The threat actors claimed to BleepingComputer that EY credentials were obtained through a supply-chain attack and used to breach the company. These stolen credentials allegedly allowed them to breach Ernst & Young's Jira, GitHub, and Azure environments.
BleepingComputer has no way to verify the threat actor's claims independently, and Ernst & Young has not confirmed that ShinyHunters was behind the attack.
The Ernst & Young third-party ITSM breach now has a claimed author. ShinyHunters added EY to its data-leak site on 2026-07-27, claiming it carried out the attack and threatening to publish the stolen data unless the firm makes contact by 2026-07-31 (BleepingComputer, 2026-07-27). At first coverage no group had claimed the intrusion.
The substantive delta is the claimed scope. The group told BleepingComputer that EY credentials "were obtained through a supply-chain attack and used to breach the company", and that those credentials "allegedly allowed them to breach Ernst & Young's Jira, GitHub, and Azure environments", issue tracking, source control and a cloud control plane, none of which appears in EY's own disclosure, which described support tickets that may contain client tax documents. The group declined to name the compromised third party or say what was taken, while asserting that the data EY acknowledged was exposed along with more (BleepingComputer, 2026-07-27). None of this is confirmed: BleepingComputer states it "has no way to verify the threat actor's claims independently, and Ernst & Young has not confirmed that ShinyHunters was behind the attack" (BleepingComputer, 2026-07-27). The report also names Experian as the provider of the 24 months of identity monitoring EY is offering affected clients, which the original coverage recorded without naming.
Triage: an intrusion of this shape presents in the downstream systems as valid-credential access, not as exploitation, successful authentications by a support-platform service account or an integration identity, arriving in the platform's normal window and often from plausible infrastructure. The discriminator is not the authentication itself but its reach: a support integration that has historically only ever read issue metadata suddenly enumerating repositories, cloning at volume, or touching cloud control-plane APIs is the deviation, and the baseline for "what this identity normally does" is the control that makes it visible.