Akira ransomware operators have added Apache OpenOffice to their leak site, asserting they stole 23 GB of data containing employee personal information and financial documents. The Apache Software Foundation (ASF) says it is reviewing the allegation but emphasized that such datasets do not exist for the OpenOffice project and that no ransom demand was received.
Akira ransomware claim: what attackers say they stole
On October 30, 2025, Akira published a post alleging a compromise of Apache OpenOffice. According to the gang, the trove includes home addresses, phone numbers, dates of birth, copies of identity documents, Social Security numbers, payment card data, financial files, and internal reports on product issues. Akira threatened to publish the data if demands are not met.
ASF response and the open-source context
ASF stated it is investigating but disputed the existence of the claimed data. OpenOffice is a volunteer-driven open-source project without a centralized employee roster or payroll for the project, and development largely occurs in public channels. Bug reports, feature requests, and technical discussions are typically open by design, making a leak of “internal reports” less plausible.
ASF also noted it has not received an extortion email—an atypical detail in a double extortion scenario, where attackers commonly contact a victim before listing them on a leak site to increase pressure.
Who is Akira? Tactics, techniques, and procedures
Active since 2023, Akira follows a double-extortion model: attackers exfiltrate data before encrypting systems, then threaten publication to maximize leverage. Joint alerts from U.S. federal agencies report that groups such as Akira frequently exploit VPNs without multi-factor authentication (MFA), perform credential theft and brute-force attacks, abuse legitimate administrative tools (living-off-the-land), and exfiltrate via cloud storage or utilities like Rclone (CISA/FBI StopRansomware: Akira).
Akira and similar gangs also use “brand-listing”—adding organizations to a leak site before proving access. This tactic heightens reputational pressure and can coerce contact even when attackers lack meaningful footholds.
Risk assessment: plausible scenarios
1) Misattribution or intentional disinformation
Given OpenOffice’s public and decentralized model, claims of large-scale employee PII, payroll, or card data appear inconsistent with how the project operates. A pressure campaign without substantiated compromise is plausible.
2) Indirect or third-party compromise
Even without centralized HR or finance systems, risks can emerge from adjacent environments: contractors, contributor endpoints, personal email accounts, CI/CD services, cloud storage, or support tools. If present, exposure would likely be peripheral rather than from ASF’s core infrastructure.
3) Limited access to private artifacts
Individual maintainers may hold private drafts, backups, or access tokens. While such items could have value, they do not align with mass datasets of “staff PII” or “cardholder data” that ASF indicates do not exist for the OpenOffice project.
Security recommendations for open-source projects and foundations
Data minimization: collect and retain only what is necessary to run the community; avoid default collection of PII. Map data flows and purge stale records on a schedule.
Enforce MFA everywhere: require MFA on email, VPN, repositories, admin consoles, and cloud accounts; prefer hardware security keys (FIDO2) and phishing-resistant methods.
Least privilege and segmentation: restrict access by role; isolate build pipelines, artifact repositories, and secrets; monitor for anomalous access patterns.
Supply chain security: sign releases (PGP/Sigstore), use reproducible builds where feasible, pin and verify dependencies, and separate build and release credentials. Track SBOMs for vulnerability exposure.
Mail security and anti-phishing: implement SPF, DKIM, and DMARC; provide regular contributor training; simulate phishing to improve resilience.
Leak monitoring and IR readiness: watch ransomware leak sites and dark web mentions; establish contact and takedown procedures; practice tabletop exercises; subscribe to CISA and FBI ransomware advisories for IOCs and mitigations.
At this stage, Akira has presented no verifiable evidence, and ASF’s statements contradict key elements of the claim. Organizations in the open-source ecosystem should treat such listings cautiously while reinforcing fundamentals: minimize data, mandate MFA, enforce least privilege, and harden the software supply chain. Monitoring official advisories and proactively exercising incident response will reduce the impact of both genuine compromises and pressure tactics based on unverified claims.
