CVE-2026-25122
Unknown Unknown - Not Provided
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
apko allows users to build and publish OCI container images built from apk packages. From version 0.14.8 to before 1.1.0, expandapk.Split drains the first gzip stream of an APK archive via io.Copy(io.Discard, gzi) without explicit bounds. With an attacker-controlled input stream, this can force large gzip inflation work and lead to resource exhaustion (availability impact). The Split function reads the first tar header, then drains the remainder of the gzip stream by reading from the gzip reader directly without any maximum uncompressed byte limit or inflate-ratio cap. A caller that parses attacker-controlled APK streams may be forced to spend excessive CPU time inflating gzip data, leading to timeouts or process slowdown. This issue has been patched in version 1.1.0.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-04
Last Modified
2026-02-20
Generated
2026-05-07
AI Q&A
2026-02-04
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
chainguard apko From 0.14.8 (inc) to 1.1.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
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.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart