06.12.2025
Finding a critical vulnerability in Aleph:
a responsible disclosure story
A flaw in the processing of 7zip archives allowed arbitrary access to files from other investigations on the same server. Here’s what we found, how it worked, and why we reported it before going public.
What Aleph is
Aleph is a data investigation platform built by OCCRP, the Organized Crime and Corruption Reporting Project, with one core purpose: helping journalists follow the money. It aggregates government records, corporate registries, and open databases into a single searchable archive, and goes beyond document search by importing structured data from spreadsheets and databases. That means a journalist can trace financial transactions, map corporate ownership, and cross-reference entities across datasets, all in one place. Users can also upload their own files, extract text, and build diagrams for their investigations. Access to sensitive parts of the archive is granted case by case to journalists and activists.
A fundamental part of Aleph is a component called ingest-file, responsible for processing files uploaded to the platform. When a journalist uploads a compressed archive, for example, ingest-file is what extracts, parses, and indexes its contents. That is exactly the component where we identified the vulnerability described in this post.
THE VULNERABILITY
The problem with 7zip archives and symbolic links
During our research, we identified that previous versions of ingest-file processed 7zip archives without properly validating the presence of symbolic links inside them.
Symbolic links, in Unix-based systems, work like shortcuts that point to other files or directories on the filesystem. Under normal circumstances, a symbolic link inside a compressed archive should only point to files contained within that same archive. What we found is that ingest-file followed these links without checking whether the target was inside the boundaries of the archive, or within the investigation the uploading user was authorized to access.
ATTACK SCENARIO
An authenticated user could craft a malicious .7z file containing a symbolic link pointing to an arbitrary path on the server’s filesystem. When uploaded to an Aleph instance, ingest-file would follow that link and index its contents as if they belonged to the attacker’s investigation.
In practice, this meant that a user could cause ingest-file to process and index files from other investigations on the same server, including sensitive investigations belonging to other journalists and organizations that the user had no authorization to access. Once indexed, that content became searchable and retrievable from within the attacker’s own investigation.
Depending on the server’s configuration, additional impact could include access to files previously uploaded to Aleph by other users, reading environment variables from the container, which frequently hold credentials and API keys, and access to secrets mounted into the container, such as certificates and authentication tokens.
All versions of ingest-file prior to 4.1.2 are affected.
RESPONSIBLE DISCLOSURE
Why we didn't publish right away
When we identify a security vulnerability in third-party software, the next question is what do we do with it.
The practice known as responsible disclosure establishes that the researcher must notify the software’s maintainers before making any information public. The goal is straightforward: give enough time for a fix to be developed, tested, and made available before malicious actors become aware of the flaw.
We followed that path. We notified the OCCRP team privately, with enough technical detail to reproduce and address the issue. From that point, the OCCRP team developed the patch and carried out validation testing, in coordination with us.
The result is ingest-file version 4.1.2, which validates and rejects 7zip archives containing symbolic links pointing outside the scope of the compressed archive. The vulnerability is fixed, and only now are we describing the technical details publicly.
This model exists because security is not a competition. Publishing a vulnerability without allowing time for a fix puts every user of the affected software at risk. In the case of Aleph, that means putting journalists at risk, many of whom operate in genuinely dangerous environments.
CREDITS
Who contributed to the resolution
Responsible disclosure: InterSecLab
Patch development (OCCRP): Alex Ștefănescu
Research, testing, and validation (OCCRP): Alex Ștefănescu, Simon Wörpel, Jan Strozyk, Friedrich Lindenberg
If you operate an Aleph instance, update the ingest-file service to version 4.1.2 as soon as possible. Technical update instructions are available in the official OCCRP advisory.
Read the full advisory.