Claimed by ShinyHunters — not confirmed by EY, which has not attributed the attackhigh
EY, client tax data and a supplier's ticketing system: what is confirmed and what is not
In early July 2026 Ernst & Young notified a breach: a third-party IT service management platform, used by its own IT personnel to support teams performing tax-related work for clients, was compromised. Support tickets may contain documents with client tax information. EY says it detected unusual activity on 23 April and determined access occurred between 28 March and 12 April. On 27 July the ShinyHunters extortion group listed EY on its leak site with a 31 July deadline. EY has not confirmed the attribution, and no data has surfaced. This dossier keeps the two levels apart.
Two stories, overlaid
When an extortion group puts a company's name on its leak site, a reading problem appears that concerns anyone who writes or reads about security: there are two overlaid stories, and they are almost always told as one. The first is what the company has stated in writing, under its own responsibility. The second is what the attackers say they hold. The two may coincide, but until they do, the difference is everything.
The Ernst & Young case this week is a clean example, and it is worth keeping separate line by line.
What EY wrote
In the breach notification — the document that carries weight, not the press line — EY describes the incident's perimeter in one precise sentence: "EY uses a third-party information technology service management platform to help EY information technology personnel provide support to EY teams performing tax-related work for clients." And it adds that support tickets submitted through the platform may include documents containing client tax information.
- 28 March 2026Unauthorised access begins
Per EY's own determination.
- 12 April 2026End of the access window
Multiple documents were downloaded in that period.
- 23 April 2026Detection
EY identifies unusual activity on the platform.
- Early July 2026Notification
EY discloses the breach; no group had claimed it yet.
- 27 July 2026Claim
ShinyHunters lists EY on its leak site.
- 31 July 2026Stated deadline
The group calls it a "final warning".
The stolen documents, per the notification, contained personal and financial information included in or used to prepare tax filings. EY says it secured its systems, removed the unauthorised access and notified federal law enforcement, and is offering affected individuals 24 months of identity monitoring and restoration services.
What EY has not disclosed matters just as much: the name of the compromised support system, the specific types of information exposed, and how many people were affected.
What the group says, and nobody has verified
On 27 July ShinyHunters added Ernst & Young to its leak site, threatening to release the allegedly stolen data if the company did not contact the group by 31 July 2026. The group told BleepingComputer it had obtained EY credentials through a supply-chain attack, and that those credentials allowed it to breach the company's Jira, GitHub and Azure environments. It also claimed that the data EY acknowledged as compromised was exposed, "along with more".
Three clarifications are needed here, and they are the most important part of this dossier.
First: the group would not identify the allegedly compromised third party, nor disclose what data it actually holds. Second: BleepingComputer explicitly writes that it has no way to verify the actor's claims independently, and that EY has not confirmed that ShinyHunters was behind the attack. Third: as of writing, no alleged EY data has appeared on underground forums.
So: the incident is confirmed by the company; the attribution is not. Those are different things, and the fastest way to lose credibility is to merge them into a headline.
Why the story matters anyway
Strip out every unverified element and one fact remains, and it concerns far more organisations than this case involves: the entry point was not an EY system. It was a supplier's platform, used by internal staff, which by the nature of that work held attachments containing end-client data.
- 01The suppliera ticketing platform for internal IT support
- 02The contentattachments with client tax information
- 03The effectend-client data leaves a system that is neither theirs nor their adviser's
That is the mechanism that makes this class of incident hard to govern. The client has a relationship with EY; EY has one with the platform vendor; the vendor, almost certainly, has one with someone else again. Accountability to the data subject does not move along that chain — but visibility does: it thins at every step.
Three questions follow, worth asking today regardless of how this ends. Which third-party systems does your internal staff use to support client work — not to deliver it, to support it? What ends up inside those systems as attachments, that is, outside the structured fields you have mapped? And how long does it stay there?
The usual answer, in practice, is that ticket attachments appear in no processing register, no risk assessment and no retention schedule. They are where people paste whatever it takes to solve a problem, and where that material then stays.
What remains to be seen
This dossier is a snapshot as of 31 July 2026, the day of the deadline the group declared. Three observable things would change the picture: a confirmation or denial from EY on attribution, actual publication of data, and identification of the third-party platform — the one element that would let other client organisations of the same vendor know whether they are in scope. Until that arrives, nobody knows that number, and caution is not pessimism: it is arithmetic.
