Nixpkgs Security Tracker

Login with GitHub

Suggestions search

With package: apko

Found 3 matching suggestions

Published
updated 2 weeks, 2 days ago by @LeSuisse Activity log
  • Created automatic suggestion
  • @LeSuisse accepted
  • @LeSuisse published on GitHub
apko is vulnerable to unbounded resource consumption in expandapk.Split on attacker-controlled .apk streams

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.

Affected products

apko
  • ==>= 0.14.8, < 1.1.0

Matching in nixpkgs

Package maintainers

Upstream advisory: https://github.com/chainguard-dev/apko/security/advisories/GHSA-6p9p-q6wh-9j89
Upstream patch: https://github.com/chainguard-dev/apko/commit/2be3903fe194ad46351840f0569b35f5ac965f09
Published
updated 2 weeks, 2 days ago by @LeSuisse Activity log
  • Created automatic suggestion
  • @LeSuisse accepted
  • @LeSuisse published on GitHub
apko affected by potential unbounded resource consumption in expandapk.ExpandApk on attacker-controlled .apk streams

apko allows users to build and publish OCI container images built from apk packages. From version 0.14.8 to before 1.1.1, an attacker who controls or compromises an APK repository used by apko could cause resource exhaustion on the build host. The ExpandApk function in pkg/apk/expandapk/expandapk.go expands .apk streams without enforcing decompression limits, allowing a malicious repository to serve a small, highly-compressed .apk that inflates into a large tar stream, consuming excessive disk space and CPU time, causing build failures or denial of service. This issue has been patched in version 1.1.1.

Affected products

apko
  • ==>= 0.14.8, < 1.1.1

Matching in nixpkgs

Package maintainers

Upstream advisory: https://github.com/chainguard-dev/apko/security/advisories/GHSA-f4w5-5xv9-85f6
Upstream patch: https://github.com/chainguard-dev/apko/commit/2be3903fe194ad46351840f0569b35f5ac965f09
Published
updated 2 weeks, 2 days ago by @LeSuisse Activity log
  • Created automatic suggestion
  • @LeSuisse accepted
  • @LeSuisse published on GitHub
apko is vulnerable to path traversal in apko dirFS which allows filesystem writes outside base

apko allows users to build and publish OCI container images built from apk packages. From version 0.14.8 to before 1.1.1, a path traversal vulnerability was discovered in apko's dirFS filesystem abstraction. An attacker who can supply a malicious APK package (e.g., via a compromised or typosquatted repository) could create directories or symlinks outside the intended installation root. The MkdirAll, Mkdir, and Symlink methods in pkg/apk/fs/rwosfs.go use filepath.Join() without validating that the resulting path stays within the base directory. This issue has been patched in version 1.1.1.

Affected products

apko
  • ==>= 0.14.8, < 1.1.1

Matching in nixpkgs

Package maintainers

Upstream advisory: https://github.com/chainguard-dev/apko/security/advisories/GHSA-5g94-c2wx-8pxw
Upstream patch: https://github.com/chainguard-dev/apko/commit/d8b7887a968a527791b3c591ae83928cb49a9f14