The European Commission Lost 350 GB to an AWS Breach. AWS’s Infrastructure Was Fine.

The European Commission disclosed on March 27, 2026 that attackers had exfiltrated roughly 91.7 GB of compressed data, on the order of 350 GB uncompressed, from the AWS infrastructure behind its Europa.eu web hosting platform. CERT-EU, the EU’s cybersecurity service for its institutions, later published a full incident analysis: the Commission’s Cybersecurity Operations Centre first received alerts about anomalous AWS API activity on March 24, notified CERT-EU on March 25, and the Commission disclosed publicly on March 27. CERT-EU and the Commission assess with high confidence that initial access happened on March 19, five days before detection, not the extended multi-week dwell time earlier reporting assumed.

The Supply Chain Compromise That Made It Possible

CERT-EU’s analysis traces initial access to the Trivy supply-chain compromise, publicly attributed to the threat actor TeamPCP. The Commission was running a poisoned version of Trivy, an open-source vulnerability scanner, received through its normal software update channel. That compromised build gave the attacker an AWS API key belonging to the Commission’s environment.

From there, CERT-EU documented a short, deliberate sequence: the attacker used TruffleHog, a secrets-scanning tool, to validate the stolen AWS credential by calling AWS’s Security Token Service (STS). The attacker then created and attached a new access key to an existing IAM user, a technique aimed at evading detection by avoiding the creation of a conspicuous new identity. Reconnaissance and exfiltration followed. CERT-EU found no evidence the attacker moved laterally into other Commission AWS accounts beyond the compromised one.

How the Breach Actually Worked

This was a supply-chain compromise, not a customer misconfiguration in the way earlier reporting framed it. The attacker did not need to find a stale, over-permissioned IAM role; a legitimate security tool the Commission trusted and updated through normal channels delivered a working credential directly. AWS’s shared responsibility model still applies, infrastructure security is AWS’s job and credential and access hygiene is the customer’s, but the entry point here was trust in a third-party software supply chain, not an abandoned integration.

The affected AWS account sits behind the Europa.eu hosting service, which the Commission uses on behalf of other EU bodies. CERT-EU said the exposure reaches up to 71 hosting clients: 42 internal Commission entities and at least 29 other Union entities. The extortion group ShinyHunters published the stolen data on its leak site on March 28, and CERT-EU’s review of the published set found personal data (names, usernames, email addresses) and roughly 51,992 files of outbound email correspondence, mostly low-content automated notifications.

Why Software Supply Chains Are the New Perimeter

In cloud environments there is no network perimeter to defend the way a traditional firewall defends one. The identity and access management configuration is the security boundary, but this incident shows that boundary can be breached without the customer misconfiguring anything: if the tooling an organization installs and updates is itself compromised upstream, it can hand over valid credentials directly.

The European Commission’s breach is instructive because it involves an organization with significant security resources and regulatory obligations. The Commission enforces GDPR, the NIS2 Directive, and the EU Cybersecurity Act, and has a dedicated cybersecurity service in CERT-EU. Despite those resources, a single poisoned software update was enough to hand an external attacker a working AWS credential. This is not a story about neglected IAM hygiene. It is a story about how much implicit trust flows through routine software updates, including updates to the security tools meant to catch exactly this kind of compromise.

Why This Pattern Is Spreading

TeamPCP’s Trivy compromise was one stage in a broader campaign against developer and cloud tooling, alongside compromises of CanisterWorm’s npm ecosystem, Checkmarx, LiteLLM, and Telnyx, documented across multiple vendor and CERT reports. The mechanism is consistent: compromise a trusted tool at the distribution layer, let normal update channels do the work of spreading it, then harvest whatever credentials the tool has access to. This scales far better for an attacker than searching for individually misconfigured roles, because it turns every downstream user of the poisoned tool into a potential victim at once.

Controls that address this class of incident: Verify the integrity of security tooling itself, not just application dependencies, since scanners and other security software are high-value supply-chain targets. Rotate and monitor credentials that security tools have access to, and alert on secret-validation patterns like repeated STS calls from tools that do not normally need them. Alert on IAM changes that create or attach new access keys to existing users, a technique specifically chosen to blend in. And apply least-privilege scoping to every credential regardless of how it was provisioned, since narrower permissions limit the blast radius even when the credential itself is compromised through a channel the customer trusted.

The Political Irony

The European Commission is simultaneously the victim of a cloud security breach and the regulator responsible for cloud security standards across the EU. The NIS2 Directive, which the Commission drafted and enforces, requires “essential entities” to implement risk management measures for network and information security, including access control and incident detection. CERT-EU’s own transparent public disclosure of the incident, including the technical root cause, is itself an example of the reporting NIS2 is meant to produce.

This does not invalidate the NIS2 Directive. It demonstrates that a sophisticated, well-resourced organization can still be compromised through a trusted software supply chain, and that writing security regulations and defending against upstream supply-chain compromise are different problems.

For cloud customers evaluating their own security posture, the lesson is direct: if the European Commission, with its resources and regulatory expertise, can be compromised through a routine update to a security tool, your organization can too. The mitigation is not only IAM hygiene, though that still matters. It is treating the software supply chain, including your security tooling, as an attack surface that needs its own verification and monitoring.

Sources: CERT-EU incident blog, “European Commission Cloud Breach: Trivy Supply Chain” (cert.europa.eu); SecurityWeek, Help Net Security, CSO Online, and Network World reporting on CERT-EU’s disclosure; AWS shared responsibility model documentation. Updated 2026-08-18: the original version of this article attributed the breach to a stale, misconfigured third-party-integration IAM role discovered after an inferred 11-week dwell time. CERT-EU’s subsequent incident analysis instead traces initial access to the Trivy supply-chain compromise on March 19, with detection on March 24, a five-day window. This version replaces the earlier causal account with CERT-EU’s documented timeline and mechanism.