European Space Agency JIRA and Bitbucket Breach: Hacker Claims 200GB Data Theft from External Servers

Executive Summary

The European Space Agency (ESA) has confirmed a cybersecurity breach affecting a small number of external servers used for collaborative engineering activities. The incident, first reported on December 26, 2025, and publicly acknowledged by ESA on December 29 and 30, 2025, involved unauthorized access to servers outside the core ESA corporate network. The threat actor, using the alias “888,” claims to have exfiltrated over 200GB of data, including source code, configuration files, API tokens, and internal documentation. ESA’s official statements and all available evidence indicate that only unclassified data was compromised, with no impact on core mission or classified systems. Forensic analysis and remediation efforts are ongoing, and all relevant stakeholders have been notified. The breach highlights the risks associated with external, collaborative infrastructure in the scientific and space sectors. All information in this summary is directly supported by the cited sources below.

Technical Information

The breach of the European Space Agency (ESA) involved unauthorized access to external servers supporting collaborative engineering activities. These servers, which included JIRA and Bitbucket instances, were located outside the ESA’s core corporate network and were used primarily for unclassified scientific collaboration. The threat actor, identified as “888,” claims to have maintained access for approximately one week, during which time they exfiltrated over 200GB of data. Screenshots posted by the attacker on BreachForums provide evidence of access to ESA’s JIRA and Bitbucket servers, though no independent forensic analysis of these samples has been published as of December 31, 2025 (BleepingComputer, 2025-12-30; TechRadar, 2025-12-31).

The attacker’s claims, corroborated by ESA’s own statements, indicate that the compromised data includes source code from private Bitbucket repositories, CI/CD pipeline configurations, API and access tokens, internal documentation, SQL database files, Terraform infrastructure code, hardcoded credentials, configuration files, and confidential documents (BleepingComputer; European Spaceflight; TechRadar). The servers in question were explicitly described by ESA as supporting “unclassified collaborative engineering activities within the scientific community,” and the agency has emphasized that the breach did not affect its core corporate network or classified systems.

The initial access vector has not been definitively confirmed by ESA or independent investigators. However, based on the attack’s characteristics and recent sector trends, the most probable methods include the use of stolen credentials (MITRE ATT&CK T1078: Valid Accounts) or exploitation of exposed, unpatched public-facing applications (T1190: Exploit Public-Facing Application). This assessment is supported by a documented increase in attacks against Atlassian products, such as JIRA and Bitbucket, using credential stuffing and infostealer logs (Push Security, 2025-03-25). The attacker’s ability to access highly privileged resources, such as source code repositories and CI/CD pipelines, suggests either the compromise of privileged accounts or misconfigured permissions.

Once inside the environment, the attacker likely leveraged the broad permissions of compromised accounts to access and exfiltrate sensitive data. The types of data stolen—source code, CI/CD configurations, API tokens, and hardcoded credentials—indicate access to highly privileged accounts or misconfigured access controls. The exfiltration of over 200GB of data over a week aligns with MITRE ATT&CK techniques T1074 (Data Staged) and T1567.002 (Exfiltration Over Web Service).

No specific malware or custom tools have been publicly identified in this incident as of the latest reporting. The attack appears to have relied on credential-based access and the native functionality of Atlassian and CI/CD platforms. Recent campaigns against Atlassian products have used infostealer malware to harvest credentials, which are then sold or used for direct access, but there is no direct evidence of such malware in the ESA breach (Push Security).

The threat actor “888” is not currently linked to a known advanced persistent threat (APT) or ransomware group in public reporting. However, the tactics, techniques, and procedures (TTPs) observed in this breach closely match those of the HELLCAT group, which has conducted a series of high-profile JIRA and Atlassian breaches since late 2024. These attacks typically involve the use of stolen credentials to access Atlassian products, exfiltrate data, and then extort or sell the stolen information. Victims of similar campaigns have included organizations in the manufacturing, telecom, automotive, and now space/scientific sectors (Push Security). While there is no direct attribution of the ESA breach to HELLCAT, the overlap in TTPs and sectoral targeting is significant.

The ESA breach is notable for its focus on external, collaborative infrastructure rather than core mission or classified systems. This reflects a broader trend in which attackers increasingly target less-protected, externally facing servers used for scientific collaboration, which often contain sensitive but unclassified data, source code, and credentials. ESA’s web shop was previously breached in 2024 via a web skimmer, further illustrating the risk to externally facing assets (BleepingComputer).

The technical details of the attack, mapped to MITRE ATT&CK, are as follows: T1078 (Valid Accounts) for the use of stolen credentials, T1190 (Exploit Public-Facing Application) for potential exploitation of unpatched servers, T1213 (Data from Information Repositories) for access and exfiltration of source code and CI/CD configs, T1552 (Unsecured Credentials) for theft of hardcoded credentials and tokens, T1074 (Data Staged) for staging data for exfiltration, and T1567.002 (Exfiltration Over Web Service) for the exfiltration of large volumes of data.

The evidence supporting these conclusions includes screenshots posted by the attacker, the types of data exfiltrated, and the nature of the compromised servers, all corroborated by ESA’s official statements and multiple independent sources. While no direct technical artifacts have been published linking the threat actor to a specific group, the pattern analysis and sectoral targeting provide a medium level of confidence in the attribution to TTPs associated with HELLCAT and similar groups.

Affected Versions & Timeline

The breach affected a small number of external servers used for collaborative engineering activities, specifically JIRA and Bitbucket instances, as confirmed by ESA and the threat actor’s claims. The servers were located outside the ESA corporate network and contained unclassified data. The incident timeline, based on verified reporting, is as follows:

The alleged breach occurred on December 18, 2025, according to the threat actor “888” (TechRadar). Reports of the breach began to emerge on X on December 26, 2025 (European Spaceflight). ESA issued its initial statement acknowledging awareness and an ongoing forensic analysis on December 29, 2025. On December 30, 2025, ESA confirmed the breach, stating that only a small number of external, unclassified servers were affected and that stakeholders had been notified (BleepingComputer; European Spaceflight). TechRadar published further details on December 31, 2025, confirming ESA’s ongoing investigation and the hacker’s claims (TechRadar).

The specific types of data compromised include source code from private Bitbucket repositories, CI/CD pipeline configurations, API tokens and access tokens, internal documentation, SQL database files, Terraform infrastructure code, hardcoded credentials, configuration files, and confidential documents. All sources emphasize that the affected servers contained only unclassified data, with no direct compromise of sensitive or classified space program information.

Threat Activity

The threat actor “888” claimed responsibility for the breach on BreachForums, offering more than 200GB of allegedly stolen data for sale. The attacker posted screenshots as proof of access to ESA’s JIRA and Bitbucket servers, though the authenticity of these samples has not been independently verified. The attacker claims to have maintained access to the compromised servers for about a week, during which time they exfiltrated source code, CI/CD pipeline configurations, API and access tokens, internal documentation, SQL database files, Terraform infrastructure code, hardcoded credentials, configuration files, and confidential documents (BleepingComputer; TechRadar).

ESA’s official statements confirm the breach and the types of data compromised, while emphasizing that only a very limited number of external servers were affected and that these servers supported unclassified collaborative engineering activities. ESA has notified all relevant stakeholders and implemented short-term remediation measures to secure any potentially affected devices. Forensic analysis is ongoing, and further updates are expected as the investigation continues (European Spaceflight).

The attack follows a pattern observed in recent campaigns targeting Atlassian products, where attackers use stolen credentials or exploit unpatched public-facing applications to gain access to source code repositories and CI/CD pipelines. The TTPs observed in this breach closely match those of the HELLCAT group, which has targeted organizations across multiple sectors using similar methods (Push Security). However, there is no direct attribution of the ESA breach to HELLCAT at this time.

Mitigation & Workarounds

The following mitigation and workaround recommendations are prioritized by severity:

Critical: Immediately review and rotate all credentials, API tokens, and access tokens associated with affected JIRA and Bitbucket instances, as well as any other external collaborative engineering servers. Revoke and reissue any hardcoded credentials and secrets found in source code or configuration files. Conduct a comprehensive audit of all privileged accounts and permissions on external servers, ensuring that only necessary access is granted and that multi-factor authentication (MFA) is enforced wherever possible.

High: Patch and update all externally facing Atlassian products, including JIRA and Bitbucket, to the latest supported versions. Review and harden the security configurations of all collaborative engineering servers, including disabling unused services, restricting access by IP address, and enforcing strong password policies. Implement network segmentation to isolate external collaborative servers from core corporate and mission-critical networks.

Medium: Conduct a thorough forensic analysis of all affected servers to identify the full scope of the breach and any potential persistence mechanisms. Monitor for signs of lateral movement or additional compromise within the environment. Notify all relevant stakeholders, including partners and collaborators who may have been affected by the breach.

Low: Review and update incident response and communication plans to ensure timely notification and remediation in the event of future breaches. Provide security awareness training to staff and collaborators on the risks associated with credential reuse, phishing, and external collaboration platforms.

These recommendations are based on the technical evidence and sector trends documented in the sources below. ESA has already implemented some short-term remediation measures and notified stakeholders, but ongoing vigilance and further hardening of external collaborative infrastructure are strongly advised.

References

BleepingComputer, December 30, 2025: https://www.bleepingcomputer.com/news/security/european-space-agency-confirms-breach-of-external-servers/

European Spaceflight, December 30, 2025: https://europeanspaceflight.com/esa-says-data-breach-was-limited-to-servers-with-unclassified-documents/

TechRadar, December 31, 2025: https://www.techradar.com/pro/security/european-space-agency-confirms-external-servers-breached-in-cyberattack

Push Security, March 25, 2025: https://pushsecurity.com/blog/why-attackers-are-targeting-jira-with-stolen-credentials

About Rescana

Rescana provides a third-party risk management (TPRM) platform designed to help organizations identify, assess, and monitor risks associated with external vendors and collaborative infrastructure. Our platform enables continuous visibility into the security posture of external assets, supports rapid incident response, and facilitates evidence-based risk mitigation. For questions or further information, please contact us at ops@rescana.com.