Description

LeafWiki extracts an uploaded ZIP archive without limiting how much data it will write. ZipExtractor.ExtractToDir in internal/importer/zip_extractor.go opens each entry and copies it to the destination with io.Copy, which runs to the end of the decompressed stream, so only the size of the uploaded archive is bounded and the size it expands to is not. The import route that reaches this code requires the Editor or Admin role, and the upload itself is capped at 500 MiB compressed. Because a ZIP entry can compress at a very high ratio, an archive well inside that cap can expand to hundreds of gigabytes as it is written out. The extraction directory defaults to a location under the operating system temporary directory, so the written data consumes the disk backing that path, which on a tmpfs-backed temporary directory is memory. A user holding the Editor role can therefore exhaust the storage the service depends on and keep it from serving, using far more resource than the upload limit alone would permit.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-26T05:18:26.117Z",
  "pubdate": "2026-08-26T05:18:26.117Z",
  "executiveSummary": "LeafWiki is susceptible to a Denial of Service (DoS) vulnerability originating from an unrestricted ZIP decompression process. The application fails to enforce size limits on the decompressed content of uploaded archives, allowing a malicious actor with Editor or Admin privileges to trigger massive disk or memory exhaustion.\nThe vulnerability stems from a lack of validation during the extraction process handled by ZipExtractor.ExtractToDir. By leveraging high compression ratios, an attacker can submit a relatively small ZIP file that expands into hundreds of gigabytes of data. This payload consumes excessive system resources, specifically targeting the storage medium of the temporary directory.\nIf the operating system utilizes a tmpfs-backed temporary directory, the extraction process can lead to immediate memory exhaustion, effectively crashing the service or the host system. The risk is significant as it allows authorized users to perform resource exhaustion attacks that disrupt availability, bypassing the 500 MiB upload cap. No specialized network access is required beyond the ability to authenticate as a privileged user and initiate an import operation.",
  "technicalDetails": "The root cause of this vulnerability is an improper implementation of file extraction logic within internal/importer/zip_extractor.go. The ZipExtractor.ExtractToDir function iterates through the entries of an uploaded ZIP archive and performs an unrestricted write operation using io.Copy. This process blindly follows the decompressed stream until the end of the archive entry, without verifying the total uncompressed size against a defined threshold.\nThe attack flow begins with an authenticated user possessing the Editor or Admin role. The attacker constructs a 'zip bomb'—an archive containing highly compressible data (such as repetitive bytes or sparse files) that achieves a massive expansion ratio. While the LeafWiki import route imposes a 500 MiB limit on the compressed archive size, this is insufficient to prevent the exhaustion of backend resources. Upon submission, the server processes the archive, and the ZipExtractor begins writing the decompressed content to the operating system's temporary directory.\nBecause the extraction destination is typically located in a system-wide temporary path, the impact depends on the configuration of that directory. If the path is backed by tmpfs, the malicious payload is written directly to system RAM. This triggers a rapid depletion of available memory, leading to potential Out-Of-Memory (OOM) errors, kernel panics, or service instability. If the directory is backed by physical disk storage, the attack leads to disk space exhaustion, potentially affecting other services or system operations that rely on the same partition for temporary storage.\nThe vulnerability is inherent to the logic of the extraction component. Exploitation is trivial for an attacker with legitimate credentials, as the system does not validate the integrity or the projected footprint of the expanded files before initiation. By bypassing storage limits through compression, the attacker effectively amplifies their resource footprint by several orders of magnitude, turning a sub-gigabyte upload into a multi-gigabyte or terabyte-scale resource contention event. Post-exploitation, the service remains unavailable until the temporary directory is cleared and the process is restarted, causing a persistent state of denial of service."
}