CVE-2025-58183

What it actually does

A vulnerability in the tar.Reader component allows for excessive memory allocation when parsing a maliciously crafted GNU tar pax 1.0 sparse file. The flaw stems from the lack of a limit on the number of sparse region data blocks, enabling an attacker to trigger an unbounded read operation that consumes significant memory resources, leading to a denial of service.

Why it matters to the business

Applications and services that process tar archives are susceptible to a denial-of-service condition. An attacker can cause these services to crash or become unresponsive by providing a specially crafted archive file. This can lead to service outages, disruption of automated workflows (like CI/CD pipelines or data ingestion systems), and reduced availability of critical systems.

How an attack unfolds

An attacker crafts a small, compressed tar archive that contains a file with a GNU tar pax 1.0 sparse format header. This header is manipulated to declare an extremely large number of sparse data regions. The attacker then delivers this archive to a target system, for example, through a file upload feature or by tricking a user into opening it. When an application using the vulnerable tar.Reader library attempts to parse the archive, it tries to allocate memory for all the declared sparse regions. This results in a massive memory allocation that exhausts system resources, causing the application to crash or become unresponsive.

How to fix it

To remediate this vulnerability, upgrade affected components to a patched version. For example, users of envoy (Bitnami) should upgrade to version 1.33.13 or later. If patching is not immediately possible, consider implementing mitigations such as restricting the processing of tar archives from untrusted sources or running archive processing in a container with strict memory limits to contain the impact of a potential DoS attack.

How to confirm the fix worked

To validate the fix, verify that all instances of the affected software have been upgraded to the patched versions specified by the vendor. You can confirm the version of the running application or library. Additionally, you can monitor systems for abnormal memory consumption or crashes related to archive processing, although the absence of such events does not guarantee immunity. The most reliable validation is confirming the patch level.

Typical attack path

1. An attacker crafts a malicious tar archive with an excessive number of sparse regions.
2. The attacker delivers the malicious archive to a target application, often through a file upload function or by tricking a user.
3. The target application uses a vulnerable library to parse the tar archive.
4. The library attempts to process the sparse file, leading to excessive memory allocation.
5. The application or the host system runs out of memory, resulting in a crash and a Denial of Service (DoS).

How to detect it

Exploitation of this vulnerability results in a denial-of-service condition caused by memory exhaustion. To detect potential exploitation attempts, security teams should monitor for and investigate application crashes, unexpected restarts, and out-of-memory (OOM) killer events on systems responsible for processing tar archives. Correlate these events with the ingestion or processing of new archive files to identify the potential trigger.

What your security team should do

• Identify all applications and systems that process tar archives and determine if they use the vulnerable library.
• Prioritize patching for internet-facing systems or critical services that accept file uploads or process external archives.
• Apply the necessary security updates to upgrade to a fixed version, such as envoy (Bitnami) 1.33.13 or newer.
• For systems that cannot be patched immediately, implement resource limiting (e.g., cgroups, container memory limits) on processes that handle archives to prevent a full system crash.