The European Space Agency got hacked. The reason why is embarrassingly preventable.

The European Space Agency has confirmed a data breach of its unclassified science servers. The theft came to light when a threat actor posted claims on social media offering to sell what they described as internal ESA data. ESA confirmed the breach is real.

What was taken is the part that hurts. The attacker walked away with source code, API tokens, access tokens for multiple ESA systems, confidential documents, system configuration files, and hardcoded credentials including embedded passwords sitting directly in the codebase. The ESA data breach 2026 was not a sophisticated nation-state operation. It was a classic insider-knowledge-style exploit that hit a well-documented weakness.

What got out

The breach affected science servers rather than ESA's operational systems, so mission control for active spacecraft is not in scope here. But the haul is still substantial. Among the potentially stolen material are subsystem requirements for the Ariel mission, a planned science mission designed to study the atmospheric chemistry of exoplanets by analysing starlight as it passes through planetary atmospheres.

Beyond Ariel, the stolen API and access tokens are the bigger near-term problem. Tokens are the keys that let software systems authenticate with each other. If any of those tokens were still active at the time of the breach, an attacker could use them to access connected systems without needing a password at all. ESA has not confirmed which tokens were revoked or when.

The breach also follows a broader surge in attacks on research and academic institutions this month. ShinyHunters hit over 100 organisations via Oracle PeopleSoft vulnerabilities, stealing student records including grades, addresses, and enrollment data from universities. The Amazon One Medical breach claim from the same group earlier this month suggested an 8.8TB haul. Research institutions are increasingly valuable targets not for financial data but for source code, credentials, and technical documentation.

The embarrassing bit: hardcoded credentials

Every cybersecurity audit in existence covers hardcoded credentials. It sits near the top of the OWASP list of common vulnerabilities. Entire tooling categories exist to scan for it automatically before code ships. And yet, a space agency of ESA's size and technical sophistication was still running systems with passwords embedded directly in the source code.

Hardcoded credentials work like this: a developer writes a database connection or an API call, and instead of reading the password from a secure secrets manager at runtime, they type it directly into the code. It works fine in local development. It then gets committed to the repository, included in every build, and eventually ends up wherever the source code ends up. Which is sometimes on a breached server.

The fix is not complicated. Secrets managers like HashiCorp Vault, AWS Secrets Manager, or even basic environment variables pull credentials at runtime rather than embedding them in the code. Tools like Gitleaks and Trufflehog scan repositories automatically for accidentally committed secrets. The reason hardcoded credentials keep appearing in high-profile breaches is not that the solution is hard. It is that scanning and remediation get deprioritised until something goes wrong.

Why space infrastructure is now a target

ESA is not the first space-adjacent organisation to be hit, and it will not be the last. Space systems represent an interesting target category: they hold proprietary engineering documentation, mission parameters, and increasingly, software that interfaces with commercial satellite networks. The Ariel subsystem requirements stolen in this breach are exactly the kind of technical detail that could inform competitive intelligence or, in a worst case, help someone understand how to disrupt a mission.

None of ESA's operational systems were confirmed as compromised in this breach. But the line between science servers and operational systems is thinner than it sounds. Science servers often share authentication infrastructure. If a stolen token grants access to a system that was never meant to be exposed, the blast radius expands.

ESA has not confirmed the identity of the attacker or the full scope of what was taken. That is not unusual at this stage of an incident response, but it does mean the organisation is still mapping what it lost.

What this means for anyone running code

The ESA breach is not just a space story. It is a reminder that credential hygiene fails at the same rate across small startups and large government agencies. The attack surface is the same: code that was written quickly, committed without a secrets scan, and never reviewed until something broke.

If you run software with any kind of external-facing API, there are three things worth doing this week. Scan your repositories for accidentally committed secrets using an automated tool. Audit which API tokens are still active and revoke anything that does not need to be. Move credentials out of code and into a secrets manager, even a basic one.

It is not glamorous work. It is also the work that prevents your organisation from appearing in a breach notification.

For broader context on what credential theft looks like at scale, 24 billion stolen credentials were found in a single exposed database this month, most of them fresh infostealer logs with plaintext passwords. The ESA breach feeds directly into that ecosystem: tokens and credentials stolen today get tested against other systems within hours.

If you want to check whether your email address has appeared in a known breach, haveibeenpwned.com is the free and reliable place to start.