CVE-2026-25122: 
NixOS vulnerability analysis and mitigation

CVE-2026-25122 is a denial-of-service vulnerability in Chainguard's apko tool — a utility for building and publishing OCI container images from APK packages — caused by unbounded resource consumption in the expandapk.Split function. The vulnerability affects apko versions >= 0.14.8 and < 1.1.0 (Go module chainguard.dev/apko). It was discovered by Oleh Konko from 1seal, disclosed on February 3, 2026, and published to the GitHub Advisory Database and NVD on February 3–4, 2026. The CVSS v3.1 base score is 5.5 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling). Specifically, the expandapk.Split function drains the first gzip stream of an APK archive using io.Copy(io.Discard, gzi) without imposing any maximum uncompressed byte limit or inflate-ratio cap. After reading the first tar header, the function reads directly from the gzip reader with no bounds, meaning a crafted APK archive with a highly compressed payload (analogous to a gzip bomb) can force the process to spend excessive CPU time on decompression. Exploitation requires user interaction — a user or automated pipeline must process an attacker-controlled APK stream — and no special privileges are required (GitHub Advisory, Patch Commit).

The sole impact is on availability: there is no confidentiality or integrity impact. A caller that parses attacker-controlled APK streams can be forced into excessive CPU consumption, leading to process slowdown, timeouts, or complete denial of service for the affected build pipeline or container image construction workflow. This is particularly relevant in CI/CD environments where apko processes externally sourced APK packages, potentially disrupting automated build and publish operations (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.013% (0.000130), placing it in the 7th percentile for exploitation likelihood within 30 days, indicating very low near-term exploitation probability (GitHub Advisory, Feedly). Exploitation is constrained by the local attack vector and the requirement for user interaction with a malicious APK file.

1. Craft a malicious APK archive: Create a specially crafted APK file containing a gzip stream with an extremely high compression ratio (gzip bomb), where a small compressed payload expands to a very large uncompressed size.
2. Deliver the malicious APK: Host the crafted APK on an attacker-controlled APK repository or deliver it through a supply chain mechanism that a target apko build pipeline would consume.
3. Trigger APK parsing: Induce the victim's apko instance (versions >= 0.14.8, < 1.1.0) to process the malicious APK — for example, by referencing the attacker-controlled repository in an apko build configuration.
4. Trigger resource exhaustion: When expandapk.Split processes the APK, it calls io.Copy(io.Discard, gzi) without bounds, causing the gzip reader to inflate the entire malicious stream and consuming excessive CPU resources.
5. Achieve denial of service: The apko process experiences severe slowdown or timeout, disrupting the container image build pipeline (GitHub Advisory, Patch Commit).

• Process: The apko process exhibiting sustained high CPU usage (near 100%) for an abnormally long duration during APK parsing or image build operations.
• Logs: Build pipeline logs showing timeouts or process hangs during APK expansion steps; error messages related to gzip decompression taking unexpectedly long.
• File System: Presence of unusually large or suspicious .apk files in build directories or cache locations that do not correspond to known-good packages.
• Network: Unexpected APK download requests to unfamiliar or untrusted repository URLs in HTTP access logs during build operations.

Upgrade apko to version 1.1.0 or later, which introduces limit readers for all external data sources including APK archives, APK indexes, and HTTP responses. The fix (commit 2be3903) adds configurable size limits via new CLI flags: --max-apk-control-size, --max-apk-data-size, --max-apkindex-decompressed-size, and --max-http-response-size, with safe defaults applied automatically. Until upgrade is possible, restrict apko to processing only trusted, verified APK sources and avoid processing APK streams from untrusted or attacker-controlled repositories (GitHub Advisory, Patch Commit).