Skip to content

Fix Dependabot vulnerability for container archive handling - #1065

Open
leogr with Copilot wants to merge 2 commits into
mainfrom
copilot/fix-dependabot-vulnerability
Open

Fix Dependabot vulnerability for container archive handling#1065
leogr with Copilot wants to merge 2 commits into
mainfrom
copilot/fix-dependabot-vulnerability

Conversation

Copilot AI commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Progress

  • Assess reachability of GHSA-x86f-5xw2-fm2r (Docker archive decompression vulnerability)
  • Remove direct github.com/docker/docker dependency by replacing homedir.Get() with standard library / helper
  • Run go mod tidy and verify downgrade of github.com/docker/docker to non-vulnerable v28.5.1+incompatible
  • Run unit tests, linting, and build validation
  • Address code review feedback by expanding unit tests for HomeDir
  • Run security scan and code review
  • Finalize PR with Reachability Assessment

Reachability Assessment

  • Advisory: GHSA-x86f-5xw2-fm2r / CVE-2026-41567 (Docker: PUT /containers/{id}/archive executes container binary on the host)
  • Affected Functionality: Docker daemon PUT /containers/{id}/archive API handling with compressed archives (xz/gzip), which decompressed using binaries resolved from the container's filesystem.
  • Reachability: Not reachable. falcoctl is a CLI tool that does not run a Docker daemon or expose/call the PUT /containers/{id}/archive container archive endpoint. In falcoctl, github.com/docker/docker was only used for homedir.Get() to determine user home directory paths, which has now been replaced with a native helper function utils.HomeDir() using Go's standard library os.UserHomeDir(). The transitive dependency on docker pulled in via driverkit is also downgraded to v28.5.1+incompatible. The codebase is not actively exposed to this vulnerability, and this change resolves the Dependabot security alert.
  • Confidence Level: High confidence.
Original prompt

This section details the Dependabot vulnerability alert you should resolve

<alert_title>Docker: PUT /containers/{id}/archive executes container binary on the host</alert_title>
<alert_description>## Summary

When a user uploads a compressed archive into a container, a malicious image can execute arbitrary code with daemon (host root) privileges.

Details

When handling PUT /containers/{id}/archive requests with compressed archives, the daemon decompresses them using external system binaries. Due to incorrect ordering of operations, these binaries are resolved from the container's filesystem rather than the host's. A container image that includes a trojanized decompression binary can achieve code execution as the daemon process whenever a compressed archive is uploaded to that container.

The executed binary runs with the daemon's full privileges, including host root UID and unrestricted capabilities.

Impact

Arbitrary code execution as host root, crossing the container-to-host trust boundary.

Conditions for exploitation

  • A user must run a container from a malicious image that contains a trojanized decompression binary.
  • The user must then upload a compressed archive (xz or gzip) into that container, either by piping a compressed archive via docker cp - or by calling the PUT /containers/{id}/archive API directly with compressed content.

Not affected

Standard docker cp usage is not affected, because the CLI sends uncompressed tar by default:

docker cp ./file.txt mycontainer:/file.txt

This can only be exploited when explicitly passing a xz or gzip-compressed archive to docker cp or the PUT /containers/{id}/archive API, for example:

cat archive.tar.xz | docker cp - mycontainer:/dir

Decompression formats using pure Go implementations (bzip2, zstd, and gzip when the container image does not contain an unpigz binary) are also not affected.

Workarounds

  • Only run containers from trusted images.
  • Use authorization plugins to limit access to the PUT /containers/{id}/archive endpoint.
  • Avoid piping compressed archives into containers created from untrusted images.</alert_description>

high
GHSA-x86f-5xw2-fm2r, CVE-2026-41567
github.com/docker/docker
go
<vulnerable_versions>= v28.5.2+incompatible</vulnerable_versions>
<patched_version></patched_version>
<manifest_path>go.mod</manifest_path>

https://github.com/moby/moby/security/advisories/GHSA-x86f-5xw2-fm2r https://nvd.nist.gov/vuln/detail/CVE-2026-41567 https://github.com/advisories/GHSA-x86f-5xw2-fm2r

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identifier explaining it is a temporary mitigation. If neither a patch nor a workaround is available, explain in the PR description why the alert cannot be resolved automatically so a human reviewer can take over. Inspect the repository to determine which package manager is used (e.g. lock files, config files, build scripts) and use that tooling to perform the update — do not edit lock files directly. If the version constraint in the manifest (e.g. package.json, Gemfile, pyproject.toml) caps the version below the fix, update the constraint first. For transitive dependencies, determine whether it is simpler to update the direct dependency that pulls in the vulnera...

Copilot AI and others added 2 commits September 1, 2026 09:48
…e to v28.5.1+incompatible

Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Signed-off-by: Leonardo Grasso <me@leonardograsso.com>
Co-authored-by: Leonardo Grasso <me@leonardograsso.com>
Signed-off-by: Leonardo Grasso <me@leonardograsso.com>
@leogr
leogr force-pushed the copilot/fix-dependabot-vulnerability branch from 53874d0 to 43be80f Compare September 1, 2026 09:49
@leogr
leogr marked this pull request as ready for review September 1, 2026 09:57
@poiana
poiana requested review from FedeDP and zuc September 1, 2026 09:57
@leogr leogr changed the title [WIP] Fix Dependabot vulnerability for container archive handling Fix Dependabot vulnerability for container archive handling Sep 1, 2026
@poiana poiana added the lgtm label Sep 1, 2026
@poiana

poiana commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

LGTM label has been added.

DetailsGit tree hash: 423009b5468f5f4f386ccc6e5b74dfbfe67c5096

@poiana poiana added the approved label Sep 1, 2026
@poiana

poiana commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Copilot, leogr

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

3 participants