CVE-2026-25122
Unbounded Gzip Inflation in apko's expandapk.Split Causes DoS
Publication date: 2026-02-04
Last updated on: 2026-02-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| chainguard | apko | From 0.14.8 (inc) to 1.1.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability exists in the apko tool, specifically in versions from 0.14.8 to before 1.1.0, within the function expandapk.Split. The function processes APK archives by reading the first gzip stream without imposing explicit limits on the amount of data decompressed. An attacker who controls the input APK stream can exploit this by crafting malicious gzip data that causes excessive inflation during decompression.
Because the function reads the gzip stream without any maximum uncompressed byte limit or inflate-ratio cap, it can force the system to spend excessive CPU time inflating the gzip data. This leads to resource exhaustion, specifically CPU exhaustion, which can cause process slowdowns or timeouts, resulting in a denial of service.
The vulnerability was fixed in version 1.1.0 by introducing configurable size limits on decompressed data to prevent such resource exhaustion attacks.
How can this vulnerability impact me? :
This vulnerability can impact you by causing a denial of service (availability impact) on systems using vulnerable versions of apko. When processing attacker-controlled APK streams, the system may be forced to spend excessive CPU resources inflating gzip data, leading to timeouts or significant process slowdowns.
The attack requires local access, low complexity, no privileges, and user interaction, but it does not affect confidentiality or integrity. The main impact is on availability, potentially disrupting normal operations or services that rely on apko for building or publishing OCI container images.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring for excessive CPU usage or process slowdowns when the apko tool processes APK archives, especially if the input is attacker-controlled. Since the vulnerability involves unbounded gzip inflation leading to resource exhaustion, detection involves observing unusually high CPU consumption or timeouts during APK processing.
To detect the vulnerability on your system, you can check the version of the apko tool installed. Versions from 0.14.8 up to but not including 1.1.0 are vulnerable.
Suggested commands to check the apko version:
- apko --version
Additionally, monitoring system resource usage during APK processing can be done using standard system tools such as:
- top or htop (to monitor CPU usage)
- ps aux --sort=-%cpu (to find processes consuming high CPU)
- strace or similar tools to trace system calls if needed
There are no specific built-in commands in apko to detect the vulnerability, but the patched version introduces configurable size limits to prevent resource exhaustion, which can be enabled to mitigate detection by limiting decompression sizes.
What immediate steps should I take to mitigate this vulnerability?
The immediate and most effective mitigation step is to upgrade the apko tool to version 1.1.0 or later, where the vulnerability has been patched.
The patch introduces configurable size limits on decompressed APK indexes, APK package sections, and HTTP responses to prevent resource exhaustion attacks such as gzip bombs and tar bombs.
If upgrading immediately is not possible, you can mitigate the risk by configuring apko to enforce size limits on decompressed data streams using the new CLI flags introduced in the patch, such as:
- --max-apkindex-decompressed-size (default 100 MB)
- --max-apk-control-size
- --max-apk-data-size
- --max-http-response-size (default 2 GB)
These limits help prevent excessive CPU usage by bounding the amount of data decompressed and processed.
Additionally, monitor your systems for unusual CPU spikes or process slowdowns during APK processing to detect potential exploitation attempts.