You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@iceberg.apache.org by "begininvoke (via GitHub)" <gi...@apache.org> on 2026/09/14 15:04:30 UTC

[I] Possible fix(deps): 4 vulnerable dependencies in go.mod [iceberg-go]

begininvoke opened a new issue, #2011:
URL: https://github.com/apache/iceberg-go/issues/2011

   This might be a false positive, but `go.mod` around line 1 looked worth a second pair of eyes.
   
   HIGH severity vulnerability (CVE-2026-41567) in github.com/docker/docker v28.5.2+incompatible. The Moby daemon resolves decompression helpers (xz, unpigz) from the CONTAINER's filesystem instead of the host when handling `PUT /containers/{id}/archive` or `docker cp -` for compressed archives. An attacker who controls a container image can ship a trojanized xz/unpigz binary; when a user uploads an xz/gzip archive into that container, the malicious binary executes with full daemon privileges — root UID on the host and unrestricted capabilities (effectively host takeover). Exploitation only requires a user to copy a compressed archive into a container built from an untrusted image, making it realistic in multi-tenant CI/CD or shared Docker environments. Fixed in Docker Engine v29.5.1 / moby v2.0.0-beta.14. Remediation: upgrade the docker/docker module to the fixed release. Until then, restrict usage to trusted images, use an authorization plugin to block the PUT /containers/{id}/ar
 chive endpoint, and avoid piping compressed archives into untrusted containers.
   
   Something like this might fix it:
   
   ```diff
   --- a/go.mod
   +++ b/go.mod
   @@ -1,6 +1,6 @@
    module github.com/yourorg/yourapp
    
    require (
    	golang.org/x/sync v0.10.0
   -	github.com/docker/docker v28.5.2+incompatible
   +	github.com/docker/docker v29.5.1+incompatible
    )
   
   Then run:
   
     go get github.com/docker/docker@v29.5.1+incompatible && go mod tidy
   
   This updates go.sum and pulls the patched Engine code (moby v29.5.1) that resolves decompression binaries from the host rather than the container filesystem. If an immediate upgrade is not possible, mitigate by only running trusted images, deploying a Docker authorization plugin that denies `PUT /containers/{id}/archive`, and forbidding `docker cp -` of xz/gzip archives into containers from untrusted images.
   ```
   
   For reference: rule `CVE-2026-41567`. Rated high.
   
   I have not run the test suite here, so treat the suggestion as a starting point rather than something ready to merge.
   
   ---
   *Found with automated scanning ([RedGem](https://code.redgem.net)) and reviewed before opening. If it is not useful, closing it is completely fine.*
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org