The Escalation Chain and the Authority Puzzle

From Trivy to EY’s tax-support documents: confirmed transitions and the unresolved Checkmarx link

Analysis based on public information available as of October 9, 2026

Abstract

In October 2026, reporting identified clients of Goldman Sachs’s wealth management business, Man Group, Tishman Speyer, and other financial institutions among those affected by a breach at Ernst & Young (EY). The compromised system did not belong to those institutions. According to EY’s breach notification, attackers accessed a third-party IT service management (ITSM) platform used to support the firm’s tax operations and downloaded client documents held there. EY says support tickets submitted through the platform may include tax documents; it does not identify the downloaded documents’ precise storage location within the platform.

Silicon UK’s account of Financial Times reporting said EY attributed the incident to a vulnerability in Checkmarx software. Earlier that year, Checkmarx had suffered a supply-chain compromise originating from Trivy, an open-source security scanner developed by Aqua Security. The Trivy incident had itself begun with the exploitation of a GitHub Actions workflow associated with an external pull request.

The apparent escalation is extraordinary. An attack beginning with a contribution to an open-source repository seemingly progressed through multiple software vendors before becoming associated with the exposure of financial information belonging to customers of major institutions.

Yet these organizations do not share a single authorization system. A GitHub workflow cannot ordinarily administer another company’s repositories, a compromised security scanner does not automatically possess its customer’s credentials, and access to a development environment does not necessarily grant permission to retrieve confidential tax documents.

The sequence therefore presents an authority puzzle: what privileges were actually needed at each transition, and which boundaries had already been crossed by legitimate business operations before the attacker arrived?

This investigation reconstructs the relevant architectures using incident reports, software documentation, EY’s public technical and tax-service materials, employment listings, contractual agreements, and financial-sector oversight disclosures.

Checkmarx confirms that the Trivy attack enabled unauthorized access to its GitHub environment and subsequent malicious distribution. Its public account does not fully reconstruct the credentials or execution path used to obtain that access. Additional open-source research identifies a plausible technical route between Checkmarx’s affected components and EY’s tax support environment. EY’s published engineering requirements mention Checkmarx, Trivy, and CI/CD technologies, while a separate role within its US Financial Services Organization describes the integration of Jira Service Management, tax operations, enterprise data platforms, and DevOps workflows.

Those materials narrow the architectural possibilities but do not prove that the relevant systems were connected in the affected environment. Nor do they establish that the malicious Checkmarx artifacts distributed in March were responsible for the EY incident.

The final exposure, however, can be understood without assuming that the attackers ever obtained authority over Goldman Sachs. Legitimate tax and support work had moved client records into EY’s technical support system before the intruder reached them. That movement could expand the information reachable by an existing support identity without granting it any privilege in the originating institution.

1. Incident Overview

Between March 28 and April 12, 2026, an unauthorized third party accessed an IT service management platform used by Ernst & Young LLP. EY’s breach notifications described the platform as a third-party service used by IT personnel to support teams providing tax services to clients. Support tickets submitted through it may include client tax documents, and the intruder downloaded documents relating to several EY clients. The notices do not specify whether the downloaded documents were ticket attachments or stored elsewhere in the platform. 1 2

EY detected unusual activity on April 23 and initiated an investigation with external cybersecurity specialists. Establishing the duration of unauthorized access was only the first part of the response. Because the affected documents concerned tax engagements involving multiple institutions and investors, the firm also needed to establish which individuals appeared in the acquired material.

The notification concerning Tishman Speyer illustrates the difficulty of this process. EY informed the company on August 6 that information concerning some of its investors might have been affected, then completed the identification of relevant individuals on August 25. That notice states that bank account numbers, income, and net worth were not included in the information affecting its recipients; the information exposed should not be assumed identical across client groups. 2

The Financial Times reported that customers of Goldman Sachs’s wealth management business and investors associated with Man Group were among those affected, as summarized in subsequent reporting by Silicon UK. Goldman Sachs said its internal systems had not been affected and client assets remained secure. EY’s notice concerning Tishman Speyer likewise said the company’s internal systems were not impacted. 3 14 2

That distinction is not a contradiction. A financial institution can retain full control of its production systems while personal information concerning its customers is exposed at a professional-services provider. The relevant data may have been transferred, replicated, processed, and stored elsewhere for legitimate business purposes.

The immediate technical incident was therefore an intrusion into EY’s support environment. The larger data exposure was made possible by the operational relationships through which documents had reached that environment.

A possible connection to a broader supply-chain compromise makes the incident more interesting.

In March 2026, Checkmarx disclosed that attackers had gained unauthorized access to its GitHub environment following the compromise of Trivy. The attackers used the acquired access to distribute malicious versions of certain Checkmarx GitHub Actions and developer extensions. Checkmarx later reported that its investigation, supported by Mandiant, had found no threat-actor access to the Checkmarx One SaaS environment or its production AWS infrastructure. The confirmed incident principally involved development and distribution systems. 4

Silicon UK’s account of the Financial Times report said EY attributed the incident to a vulnerability in Checkmarx software. That reported attribution is more substantial than an association inferred from overlapping dates. It still does not identify the affected Checkmarx component, the entry point into EY, or a connection to the malicious artifacts distributed in March. 14

Thus, the public record supports two separately reported facts: Checkmarx suffered a Trivy-origin supply-chain compromise, and subsequent reporting relayed EY’s attribution of its ITSM incident to a Checkmarx software vulnerability. Whether the March malicious artifacts caused the EY incident remains unresolved.

Two-lane architecture map. A confirmed Trivy workflow compromise leads to Aqua distribution authority and Trivy-origin access to Checkmarx; a dashed route from Checkmarx through an unidentified EY execution context to the breached ITSM is unproven. Separately, financial client information enters EY tax services, and documents appear in the ITSM through an undisclosed copying path. — Figure 1. Reported incident relationships and information custody are different paths. The Checkmarx-to-EY connection and the ITSM entry route remain unconfirmed; the diagram does not identify the ITSM as Jira.

2. Timeline of the Compromise

The relevant chronology contains several different types of events: initial exploitation, acquisition of credentials, malicious software distribution, unauthorized document access, incident detection, and public disclosure.

Date, 2026	Event
February 27	Attackers exploit a vulnerable `pull_request_target` workflow in Trivy and obtain repository- and organization-level secrets belonging to Aqua Security.
February 27	A malicious Trivy VS Code extension is published through Open VSX.
February 28–March 1	Further credential acquisition and activity involving additional compromised identities occur.
March 19	Attackers distribute a malicious Trivy release. Checkmarx subsequently identifies the Trivy compromise as the origin of unauthorized access to its GitHub environment.
March 22	Additional Aqua repositories and Trivy distribution channels are affected.
March 23	Malicious Checkmarx GitHub Actions and Open VSX extensions are distributed.
March 28–April 12	Unauthorized access to EY’s third-party ITSM platform occurs, and documents concerning multiple clients are downloaded.
April 22	Further malicious Checkmarx distribution activity is identified.
April 23	EY detects unusual activity in the affected ITSM environment.
August–September	Further identification and notification of affected individuals and client organizations continue.
October	Financial Times reporting identifies information concerning Goldman Sachs, Man Group, and other EY clients among the affected data.

Aqua’s final incident report confirms the progression from the February workflow exploitation to broader credential acquisition and malicious releases in March. Checkmarx independently confirms that the Trivy incident enabled unauthorized access to its own GitHub environment. 4 5

The evidence concerning EY is more complicated. Its notices establish access to the support platform and document downloads, but do not identify the intruder, initial entry point, or authority used to retrieve the files. For an authority analysis, those missing capabilities matter more than the chronological proximity of the incidents.

The chronology provides a possible sequence, but the technical chain must be established separately.

3. The Distinct Authority Boundaries

The diagram separates two movements that a single incident timeline can obscure. Attackers must acquire authority to execute code, use an identity, or retrieve a protected document. Organizations can also move information into a different system through authorized work, changing which existing identities can reach a copy.

At Aqua, an external pull request reached a privileged workflow and then broader automation credentials. The pull-request author did not possess release authority; the compromised execution context exposed identities that did. Checkmarx confirms that the Trivy attack later enabled access to its GitHub environment, though the exact credential path is not public. An Aqua token alone would not normally authorize Checkmarx repository changes. 4 5

At EY, the public notice establishes document access through a third-party ITSM, while the route into that platform remains unknown. Even if malicious Checkmarx code ran in an EY workflow or workstation, a source-control token, cloud identity, and support-platform session would confer different permissions. The question is which capability actually reached the documents.

The financial-data exposure involved a second boundary. EY held client information for tax services, and client documents were present in the ITSM. Once copied into that environment, access to those copies could be governed by support roles rather than the originating financial institution’s permissions. That possibility does not establish the ITSM’s configuration or the attacker’s retrieval identity. It identifies why exposure across several institutions need not represent separate intrusions into each institution.

4. Reverse-Engineering the Architecture

4.1 Aqua: Independent Projects and Shared Automation Authority

Aqua’s post-incident report describes Trivy as an independently managed open-source project within a broader corporate GitHub environment. Although the project had its own repository and maintainers, highly privileged service accounts were shared across projects without sufficient isolation. 5

This distinction between organizational structure and effective technical permissions is central to the initial compromise.

A development organization may treat repositories as separate projects while relying on common automation identities for routine maintenance, review assignment, dependency updates, release management, and software publication. These activities require different capabilities, but the identities performing them may possess authority across several repositories.

The initial attack exploited a workflow triggered through pull_request_target. This GitHub Actions event operates in the security context of the base repository rather than an external contributor’s fork. It can be appropriate for trusted administrative operations, but becomes dangerous when attacker-controlled code is executed in that context.

A related September 2026 GitHub Security Lab advisory concerning a Trivy fork maintained by Datadog illustrated the underlying failure mode. The workflow checked out material derived from an external pull request and invoked a local action whose contents the contributor could influence. The analyzed fork is not a complete historical copy of Aqua’s original workflow, but demonstrates how apparently administrative automation can execute untrusted code with privileged access. 6

Aqua’s actual incident then involved an additional authority relationship: privileged credentials accessible through the affected automation.

The distinction between a repository-scoped GITHUB_TOKEN and a separately provisioned service-account token is important. A service-account token derives its permissions from the identity and scope associated with that token. If an automation account can modify several repositories, its credential may be valid across those repositories even when the workflow exposing it belongs to a single project.

Possession of such a credential does not automatically reveal all repository secrets. GitHub’s ordinary secrets APIs do not return stored plaintext values. Further acquisition requires access to execution environments or workflows in which those secrets can become available.

Aqua reported that attackers executed workflows in additional repositories to obtain more secrets. Consequently, the initial compromise did not merely provide access to a larger set of files; it enabled operations through which additional identities and distribution credentials could be acquired.

This also explains why early credential rotation failed to contain the attack completely. Aqua found that after credentials associated with one compromised user had been revoked, activity continued through another compromised identity. A token observed in March 1 activity was subsequently associated with the March 19 compromise.

The effective architecture therefore consisted of repositories, workflows, automation accounts, secrets, and release systems connected by pre-existing authorization relationships.

The attacker did not need to make GitHub grant extraordinary permissions to an external contributor. It needed to reach an identity that already possessed authority beyond the intended boundary of the original workflow.

4.2 Checkmarx: Distribution Authority Becomes Customer-Side Execution

Checkmarx introduces another important distinction: controlling a software distribution channel is not the same as controlling the organization that consumes its products.

Checkmarx distributes tools through several mechanisms, including GitHub Actions, IDE extensions, Jenkins integrations, and other developer-facing components. Some operations involve its SaaS platform, while others involve executable artifacts running in customer-controlled environments.

Its investigation found that attackers had compromised development and distribution infrastructure but had not accessed the Checkmarx One SaaS production environment. That limits explanations based on direct access to centrally hosted customer data or SaaS integration secrets. 4

A compromised GitHub Action instead offers a different path. The malicious code executes inside the customer’s workflow, where its practical capabilities depend on the runner, filesystem, process environment, and accessible credentials.

A tool legitimately intended to scan source code is not necessarily confined to source-code permissions. If the CI job makes repository credentials, API keys, cloud credentials, or configuration material accessible to executable steps, malicious code may attempt to obtain them.

Checkmarx’s incident advisory explicitly identified those types of credentials as potentially exposed through the affected GitHub Actions. It also identified a separate exposure involving Open VSX extensions, where malicious code could encounter tokens, configuration files, and credentials available in a developer’s environment. 4

These are different propagation models.

A CI-based compromise may acquire automation credentials, repository permissions, cloud deployment identities, or publishing tokens. A compromised IDE extension may instead operate within the security context of an actual developer, potentially encountering credentials associated with interactive services.

Checkmarx identified malicious distribution activity on March 23, including affected GitHub Actions and Open VSX extensions. The distribution windows were limited, so use of Checkmarx software alone does not establish compromise. A customer-side execution hypothesis requires identifying the affected artifact, version or reference, installation or execution time, and credentials reachable from that environment.

This is why the confirmed propagation from Trivy to Checkmarx cannot simply be extended to every Checkmarx customer. The software distributor provides the opportunity for code execution, but the consuming environment determines which authority, if any, the malicious code can acquire.

4.3 EY’s Development Environment: A Plausible Consumer of the Affected Technology

Additional open-source investigation provides a more concrete picture of EY’s technical practices.

An EY DevSecOps and AI Engineer recruitment listing describes building and maintaining CI/CD pipelines using technologies including GitHub Actions, GitLab CI, Jenkins, and Azure DevOps. The same role identifies integration of security tools including Checkmarx and Trivy as part of continuous security scanning. 7

Another EY tax technology recruitment listing, dated October 7, 2026, describes application development using Azure and .NET technologies, CI/CD automation through GitHub Actions and Azure DevOps, and experience with Checkmarx as an application security tool. 8

These materials matter because they connect the relevant technologies within EY’s published engineering model. Checkmarx, Trivy, Azure, and GitHub Actions are not merely an arbitrary collection of products selected to make a hypothetical attack plausible; they are technologies appearing in the firm’s own recruitment requirements.

The evidence nevertheless has important limits. The DevSecOps role concerns EY’s technology organization in India, and some such positions may involve client delivery rather than the firm’s own internal infrastructure. The October tax technology listing also postdates the incident and does not establish what was deployed in March. Neither proves that the specific EY US tax environment affected by the breach executed a compromised Checkmarx artifact.

What they establish is narrower but useful: an architecture that combines Checkmarx with CI/CD and enterprise cloud credentials is consistent with publicly described EY engineering practices.

The same research suggests two distinct customer-side compromise hypotheses.

Under a CI execution model, an EY workflow would have executed an affected Checkmarx GitHub Action during its distribution window, or retained an affected artifact for later execution. Malicious code would then attempt to acquire credentials accessible within that runner. Depending on the environment, those credentials might grant access to source control, cloud resources, service APIs, or other connected systems.

Under a workstation execution model, a developer would install or automatically update a compromised Checkmarx Open VSX extension. The code would execute in the developer’s environment, potentially exposing credentials or configuration material associated with that person’s work.

The second model is especially interesting when considering an eventual transition into Jira or IT support. An interactive development environment may contain identities and service connections that differ from the automation credentials available in CI.

Neither model establishes that the attacker reached EY’s ITSM. But they replace an abstract statement about a vendor compromise with concrete execution contexts and specific categories of credentials that could be investigated.

4.4 EY’s Financial Tax Organization: Jira, Support Operations, and Data Platforms

A second set of public materials brings the potential destination into sharper focus.

EY advertised a senior management role titled Financial Services — Tax Technology Atlassian Lead within its US Financial Services Organization, or FSO. The role concerns the coordination and governance of Atlassian technology across multiple financial-services tax groups. 9

Its responsibilities include standardizing Jira and related environments, establishing a centralized support function, using Jira Service Management for service delivery, improving data governance and access management, and integrating Atlassian technologies with enterprise data platforms and DevOps pipelines.

The listing also describes the existing environment as fragmented and calls for its transformation into a more coherent enterprise operating model.

This listing places development workflows, enterprise data systems, Jira, service management, and access governance within the responsibilities of a tax technology function. It describes a role, not the configuration of the breached environment.

It also limits what can be inferred. A job advertisement is a statement of organizational requirements and planned responsibilities, not an infrastructure inventory. It may describe systems that already exist, systems being consolidated, or capabilities that the organization intends to implement. The listing postdates the March–April incident and does not identify the third-party ITSM involved in that incident.

It therefore supplies a concrete hypothesis to test about financial tax support operations, while leaving the affected ITSM product unidentified.

A support ticket might be created because a dataset failed validation, a report was generated incorrectly, an investor record could not be reconciled, or an application encountered an unexpected result. Resolving the problem might require IT personnel to examine logs, application state, or documents used in the relevant transaction. These are examples of support work, not a reconstruction of why the affected documents were copied into the platform.

This offers a plausible operational reason for tax information to appear in a technical support environment. EY’s breach notification confirms that client documents were present in the ITSM, although it does not establish where the downloaded documents were stored within it or why they had been copied there.

The important architectural distinction concerns the organization of access permissions.

A tax-processing platform may organize information by investor, fund, client institution, engagement, or reporting responsibility. An ITSM platform may instead organize access around service projects, tickets, support teams, assignment groups, and internal user roles.

Once a document is copied from the tax-processing environment into an ITSM platform, access to that copy may depend on the platform’s authorization model. A ticket attachment is one possible storage path, not a confirmed location for the downloaded files.

The two permission structures do not necessarily preserve the same boundaries.

4.5 Jira Service Management: When a New Escalation May Not Be Necessary

The potential relationship between Jira and the affected ITSM requires closer examination because it changes the apparent authority puzzle.

Atlassian’s documentation describes several ways Jira Service Management can authorize access to service requests. In team-managed service projects, the internal access level can be configured as Open or Private. An Open configuration allows internal users of the relevant Jira site to view service requests according to the documented access model, while a Private configuration restricts access to administrators and explicitly included users. 10

Other configurations use project permissions, roles, and issue-level security restrictions. Atlassian’s documentation on exporting attachments also identifies project browsing permissions and applicable issue security as requirements for retrieving the corresponding files. 11

These details matter because access to Jira and access to Jira Service Management are not necessarily separated by another authentication boundary.

If a compromised identity is already recognized by the relevant Jira site and has permission to browse the affected service requests, that identity may be able to retrieve attachments without obtaining another administrative credential or compromising another application.

A project could, for example, be configured to provide a shared internal support group with access to tickets covering several business units. In that configuration, the effective authorization boundary might be the support project’s membership or role assignments rather than the financial institution to which a document originally belonged.

This does not mean that EY used such a configuration.

There is no public confirmation that the compromised ITSM was Jira Service Management, that it shared a Jira site with EY’s development environment, or that its access settings allowed broadly shared visibility.

The value of Atlassian’s published authorization model is that it demonstrates an alternative to the assumption that a separate privilege escalation was required between Jira access and ITSM document access.

If the relevant identity already possessed document-reading permission, the attacker’s additional requirement would have been to acquire that identity, not to elevate its privileges after acquiring it.

4.6 EY’s Contracts: Professional Services and Internal Support

The movement of client information into a technical support environment also has a contractual dimension.

A useful primary source is the Master Services Agreement dated October 16, 2023, between Ernst & Young LLP and Calamos Trusts, publicly filed with the SEC. 12

This agreement does not govern the affected Goldman Sachs engagement, and it cannot establish whether EY’s use of the compromised ITSM complied with the relevant client contract. It does, however, provide a documented example of the contractual structure employed by the same US EY legal entity.

Section 4(h) defines Internal Support Services to include activities such as administrative support, business applications, system management, data security, storage, and recovery. Section 4(m) defines Support Providers to include external service providers and related subcontractors.

Section 6 generally requires prior written client consent when EY subcontracts professional services to certain third parties. Section 20 separately contemplates access to client information by other EY entities, EY personnel, and Support Providers in connection with service delivery and internal support.

This distinction is important. Delegating the preparation of tax filings to another professional-services firm and engaging an IT provider to support EY’s tax operations need not be governed by identical approval requirements.

The agreement also preserves obligations. Section 20 assigns EY responsibility for relevant uses and disclosures by entities and providers acting in these capacities, while Section 21 addresses technical and organizational protections and provider obligations concerning personal information.

The contract therefore does not provide unrestricted authority to move client documents into arbitrary systems. It recognizes that internal support and external technology services may legitimately process client information while remaining subject to security and confidentiality requirements.

A further provision is relevant. Section 24 describes circumstances in which EY operates as an independent controller of personal information under applicable law and engagement terms. This reflects the degree of professional and operational judgment that may be involved in delivering services, rather than an arrangement in which every technical processing decision is necessarily specified by the client.

Again, the provision does not establish the terms of the affected engagement or justify any particular implementation.

Its significance is architectural: contractual authorization to perform professional services, authorization to engage support providers, and technical permission to retrieve documents from a support platform represent different relationships.

A contract can permit a category of processing without defining the exact application permissions governing each support ticket.

4.7 Goldman Sachs: Oversight Does Not Necessarily Follow Every Data Copy

The financial institution’s perspective introduces another system of authority: assurance and oversight.

Goldman Sachs said its internal systems were unaffected and client assets remained secure. That statement identifies where the intrusion did not occur; it does not establish how each copy of client information held by EY was protected before the breach. 14

The broader US financial regulatory framework recognizes that financial institutions remain responsible for managing risks arising from third-party relationships. The Federal Reserve, FDIC, and OCC’s 2023 interagency guidance discusses due diligence, contracts, subcontractors, information security, monitoring, audit, and incident response. 13

Such oversight does not necessarily require a financial institution to administer or directly audit every system operated by every supplier and subcontractor. The evaluation may depend on the services involved, applicable contract terms, assurance reports, and the provider’s own third-party management practices.

The difficult question is whether the scope of those assessments corresponds to the actual locations and permission structures through which the institution’s information is processed.

A tax-service assessment may examine controls surrounding the primary tax application, while technical support systems, document attachments, platform administration, and external infrastructure providers may be covered by separate controls or assurance arrangements.

It would be incorrect to infer that EY’s ITSM was excluded from Goldman Sachs’s actual assessment. The relevant pre-incident assurance scope has not been publicly disclosed.

The relevant issue is whether the data locations and authorization relationships created by EY’s actual support operations were represented appropriately in the risk assessments and assurance mechanisms governing the engagement. The public record does not disclose the scope of Goldman Sachs’s pre-incident assessment of the affected platform.

5. What Would Settle the Authority Puzzle?

The Aqua workflow compromise and Trivy-origin access to Checkmarx establish two different acquisitions of technical authority. Section 4 explains how those boundaries could be crossed. The unresolved part begins at EY: its notification establishes access to a third-party ITSM and document downloads, while subsequent reporting relays EY’s attribution to a Checkmarx software vulnerability. Neither account identifies the attacker’s initial foothold in EY, the affected component, or the identity used to retrieve the documents. 2 14

5.1 Entry into EY: competing explanations

The known March Checkmarx artifacts create possible execution contexts, not an observed EY intrusion trace. A GitHub Action would run in a CI job; an Open VSX extension would run in a developer’s environment. Either could expose only the credentials and capabilities available there. A separate Checkmarx vulnerability could operate differently, and an independent ITSM route would not require the March artifacts at all.

Candidate route	Evidence that would distinguish it
Compromised Checkmarx GitHub Action	EY workflow logs showing the affected Action and execution time; runner credentials; subsequent use of those credentials
Compromised Checkmarx Open VSX extension	Installation and execution on an EY workstation; credential exposure; the identity used afterward
Separate Checkmarx software vulnerability	Affected product, vulnerability or failure mode, and a victim-specific link to EY’s support environment
Independent ITSM entry	Platform authentication or exploit records showing access without a Checkmarx-derived capability

The March 23 artifact distribution preceded the March 28 start of reported document access. That timing permits earlier credential theft or persistent access, but proves neither. It does not identify an EY execution context or the capability used to retrieve the documents. 4 2

5.2 The authority that retrieved the documents

Even a confirmed Checkmarx execution at EY would not complete the causal chain. A repository token could not simply be used as an ITSM session; a cloud identity would need an additional path to the documents. Possessing credential material would not itself establish a usable session if authentication controls blocked it. The decisive evidence is the capability exercised at the support platform.

Retrieval model	Records needed to test it
One support identity already authorized across multiple client documents	Identity and role assignments, document-access logs, and ticket visibility if the files were attached to tickets
Several restricted identities or an additional privilege change	Authentication history, role changes, and the sequence of requests across client boundaries
Administrative or storage-layer access outside ordinary document viewing	Administrator events, storage access logs, and comparison with application-level audit records

Atlassian documents a Jira Service Management configuration in which internal Jira users can view service requests, making the first model technically possible. EY has not identified its breached ITSM as Jira or disclosed its permissions. A role advertised in an EY job listing cannot fill that evidentiary gap. 9 10

5.3 Where information changed authority domains

The document exposure has a firmer explanation than the entry route. EY’s notices say support tickets may include client tax documents and that an unauthorized party downloaded documents concerning multiple clients from the platform. They do not identify the downloaded files’ precise location within it. The financial institutions’ own systems did not have to be compromised for those copies to be exposed. 2 14

The act of placing a document in a support platform can change which permission model governs that copy. A tax system may separate records by client or investor; a support platform may organize access by project, assignment group, operational role, or storage layer. If one support identity can legitimately view documents spanning several engagements, stealing that identity could enlarge the attacker’s information reach without a new grant of privileges at each client. If the platform instead enforced client-specific separation, the attacker needed more identities or a different access layer. The public record does not distinguish those cases.

This is neither a finding that EY’s ITSM was misconfigured nor a claim that a particular support worker had broad access. The EY–Calamos agreement shows why internal support and external providers can legitimately process client information while remaining subject to security duties; it does not govern the affected Goldman Sachs engagement. The open question is whether each support copy retained protections suited to its client and investor origin, and whether that copy was included in the relevant assurance scope.

The distinction is operationally sharp: acquiring a new credential crosses a technical boundary; copying a document into a support workflow can move information into the reach of an existing credential. The same breach may involve both mechanisms, but evidence for one does not establish the other.

Conclusion

The public record confirms the Trivy-origin compromise of Checkmarx and the theft of tax-related documents from EY’s support platform. It does not establish that the malicious Checkmarx artifacts distributed in March caused the EY intrusion. The affected component, initial EY foothold, and document-reading identity remain undisclosed.

Yet the most consequential boundary in the financial-data exposure does not depend on solving that link. Goldman Sachs could control access to its own systems and still have client information exposed in documents held by EY. Once a copy entered EY’s support platform, its practical protection depended on that platform’s identities, roles, and document-access controls. The originating institution’s access rules did not automatically travel with the document.

No new authority over Goldman Sachs was needed to read information already held elsewhere. Ordinary service delivery can therefore widen the effective reach of an existing support identity without anyone deliberately granting that identity a new privilege over the institution’s systems. Whether a single broadly authorized identity, several restricted identities, or administrative access was used at EY remains unknown.

This does not prove a misconfiguration or a contractual failure. It makes a more demanding question unavoidable: when sensitive client information is copied into operational support, who can reach that copy, and is the copy within the controls and assurance that the client believes protect its data? A third-party review that maps vendors but not their support copies and permissions may miss the boundary that determines exposure.