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/[email protected]+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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to