chore(deps): bump moby/client v0.4.0, moby/api v1.54.1#3634
Merged
mdelapenya merged 1 commit intotestcontainers:mainfrom Apr 3, 2026
Merged
chore(deps): bump moby/client v0.4.0, moby/api v1.54.1#3634mdelapenya merged 1 commit intotestcontainers:mainfrom
mdelapenya merged 1 commit intotestcontainers:mainfrom
Conversation
Update to tagged versions. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
✅ Deploy Preview for testcontainers-go ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Summary by CodeRabbit
WalkthroughUpdated Go module dependencies across the project from dated pseudo-versions to stable tagged releases for Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Contributor
Author
|
cc @mdelapenya now with fancy schmanzy tags 😄 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docker.go`:
- Around line 1063-1065: The call to jsonmessage.DisplayStream is missing the
required third parameter; update the call in docker.go where
jsonmessage.DisplayStream(resp.Body, img.BuildLogWriter()) is invoked to include
an auxCallback (pass nil if no auxiliary handling is needed) so it matches the
signature func DisplayStream(in io.Reader, out io.Writer, auxCallback
func(jsonstream.Message)) error; keep the existing error handling (return "",
fmt.Errorf("build image: %w", err)).
In `@modules/azure/go.mod`:
- Line 19: The go.mod currently pins non-existent/unstable versions; update the
dependency versions to official releases by changing the moby module lines so
that github.com/moby/moby/api is pinned to v1.54.0 (not v1.54.1) and
github.com/moby/moby/client is pinned to v0.3.0 (not v0.4.0); if you intended to
use pre-release builds, replace those entries with a clear comment and/or a
replace directive and ensure CI handles fetching the pseudo-version, but
otherwise fix the version strings in the go.mod entries for
github.com/moby/moby/api and github.com/moby/moby/client to the official release
tags.
In `@modules/dind/go.mod`:
- Around line 8-9: The go.mod entries claim module versions that likely don't
exist; verify and correct the two module versions by checking the real tagged
releases for github.com/moby/moby/api and github.com/moby/moby/client and then
update the go.mod lines (the entries containing "github.com/moby/moby/api" and
"github.com/moby/moby/client") to the actual available tags (e.g., change api to
v1.54.0 and client to v0.3.0 if those are the confirmed latest stable releases)
or to the exact versions you confirm are intended so module resolution succeeds.
In `@modules/socat/go.mod`:
- Around line 38-39: Update the indirect moby dependencies in go.mod to use
actual released versions: change github.com/moby/moby/api from v1.54.1 to
v1.54.0 and github.com/moby/moby/client from v0.4.0 to v0.3.0, then run `go mod
tidy` (or the Go toolchain equivalent) to refresh go.sum and ensure no other
modules require different versions; verify build and tests to confirm
compatibility.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 99992c9c-f86c-43d9-963c-8b91418fce06
⛔ Files ignored due to path filters (66)
examples/nginx/go.sumis excluded by!**/*.sumgo.sumis excluded by!**/*.summodules/aerospike/go.sumis excluded by!**/*.summodules/arangodb/go.sumis excluded by!**/*.summodules/artemis/go.sumis excluded by!**/*.summodules/azure/go.sumis excluded by!**/*.summodules/azurite/go.sumis excluded by!**/*.summodules/cassandra/go.sumis excluded by!**/*.summodules/chroma/go.sumis excluded by!**/*.summodules/clickhouse/go.sumis excluded by!**/*.summodules/cockroachdb/go.sumis excluded by!**/*.summodules/compose/go.sumis excluded by!**/*.summodules/consul/go.sumis excluded by!**/*.summodules/couchbase/go.sumis excluded by!**/*.summodules/databend/go.sumis excluded by!**/*.summodules/dind/go.sumis excluded by!**/*.summodules/dockermcpgateway/go.sumis excluded by!**/*.summodules/dockermodelrunner/go.sumis excluded by!**/*.summodules/dolt/go.sumis excluded by!**/*.summodules/dynamodb/go.sumis excluded by!**/*.summodules/elasticsearch/go.sumis excluded by!**/*.summodules/etcd/go.sumis excluded by!**/*.summodules/forgejo/go.sumis excluded by!**/*.summodules/gcloud/go.sumis excluded by!**/*.summodules/grafana-lgtm/go.sumis excluded by!**/*.summodules/inbucket/go.sumis excluded by!**/*.summodules/influxdb/go.sumis excluded by!**/*.summodules/k3s/go.sumis excluded by!**/*.summodules/k6/go.sumis excluded by!**/*.summodules/kafka/go.sumis excluded by!**/*.summodules/localstack/go.sumis excluded by!**/*.summodules/mariadb/go.sumis excluded by!**/*.summodules/meilisearch/go.sumis excluded by!**/*.summodules/memcached/go.sumis excluded by!**/*.summodules/milvus/go.sumis excluded by!**/*.summodules/minio/go.sumis excluded by!**/*.summodules/mockserver/go.sumis excluded by!**/*.summodules/mongodb/go.sumis excluded by!**/*.summodules/mssql/go.sumis excluded by!**/*.summodules/mysql/go.sumis excluded by!**/*.summodules/nats/go.sumis excluded by!**/*.summodules/nebulagraph/go.sumis excluded by!**/*.summodules/neo4j/go.sumis excluded by!**/*.summodules/ollama/go.sumis excluded by!**/*.summodules/openfga/go.sumis excluded by!**/*.summodules/openldap/go.sumis excluded by!**/*.summodules/opensearch/go.sumis excluded by!**/*.summodules/pinecone/go.sumis excluded by!**/*.summodules/postgres/go.sumis excluded by!**/*.summodules/pulsar/go.sumis excluded by!**/*.summodules/qdrant/go.sumis excluded by!**/*.summodules/rabbitmq/go.sumis excluded by!**/*.summodules/redis/go.sumis excluded by!**/*.summodules/redpanda/go.sumis excluded by!**/*.summodules/registry/go.sumis excluded by!**/*.summodules/scylladb/go.sumis excluded by!**/*.summodules/socat/go.sumis excluded by!**/*.summodules/solace/go.sumis excluded by!**/*.summodules/surrealdb/go.sumis excluded by!**/*.summodules/tidb/go.sumis excluded by!**/*.summodules/toxiproxy/go.sumis excluded by!**/*.summodules/valkey/go.sumis excluded by!**/*.summodules/vault/go.sumis excluded by!**/*.summodules/vearch/go.sumis excluded by!**/*.summodules/weaviate/go.sumis excluded by!**/*.summodules/yugabytedb/go.sumis excluded by!**/*.sum
📒 Files selected for processing (67)
docker.goexamples/nginx/go.modgo.modmodules/aerospike/go.modmodules/arangodb/go.modmodules/artemis/go.modmodules/azure/go.modmodules/azurite/go.modmodules/cassandra/go.modmodules/chroma/go.modmodules/clickhouse/go.modmodules/cockroachdb/go.modmodules/compose/go.modmodules/consul/go.modmodules/couchbase/go.modmodules/databend/go.modmodules/dind/go.modmodules/dockermcpgateway/go.modmodules/dockermodelrunner/go.modmodules/dolt/go.modmodules/dynamodb/go.modmodules/elasticsearch/go.modmodules/etcd/go.modmodules/forgejo/go.modmodules/gcloud/go.modmodules/grafana-lgtm/go.modmodules/inbucket/go.modmodules/influxdb/go.modmodules/k3s/go.modmodules/k6/go.modmodules/kafka/go.modmodules/localstack/go.modmodules/mariadb/go.modmodules/meilisearch/go.modmodules/memcached/go.modmodules/milvus/go.modmodules/minio/go.modmodules/mockserver/go.modmodules/mongodb/go.modmodules/mssql/go.modmodules/mysql/go.modmodules/nats/go.modmodules/nebulagraph/go.modmodules/neo4j/go.modmodules/ollama/go.modmodules/openfga/go.modmodules/openldap/go.modmodules/opensearch/go.modmodules/pinecone/go.modmodules/postgres/go.modmodules/pulsar/go.modmodules/qdrant/go.modmodules/rabbitmq/go.modmodules/redis/go.modmodules/redpanda/go.modmodules/registry/go.modmodules/scylladb/go.modmodules/socat/go.modmodules/solace/go.modmodules/surrealdb/go.modmodules/tidb/go.modmodules/toxiproxy/go.modmodules/valkey/go.modmodules/vault/go.modmodules/vearch/go.modmodules/weaviate/go.modmodules/yugabytedb/go.mod
| github.com/Azure/azure-sdk-for-go/sdk/storage/azblob v1.6.0 | ||
| github.com/Azure/azure-sdk-for-go/sdk/storage/azqueue v1.0.0 | ||
| github.com/moby/moby/api v1.54.1-0.20260401134807-948d5691a093 | ||
| github.com/moby/moby/api v1.54.1 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the moby/moby/api and moby/moby/client versions exist and check for security advisories
echo "=== Checking moby/moby/api v1.54.1 ==="
gh api repos/moby/moby/git/refs/tags/api/v1.54.1 --jq '.object.sha' || echo "Tag not found"
echo -e "\n=== Checking moby/moby/client v0.4.0 ==="
gh api repos/moby/moby/git/refs/tags/client/v0.4.0 --jq '.object.sha' || echo "Tag not found"
echo -e "\n=== Checking for security vulnerabilities in moby packages ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: GO, package: "github.com/moby/moby") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
echo -e "\n=== Checking sirupsen/logrus v1.9.4 ==="
gh api repos/sirupsen/logrus/git/refs/tags/v1.9.4 --jq '.object.sha' || echo "Tag not found"
echo -e "\n=== Checking for security vulnerabilities in logrus ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: GO, package: "github.com/sirupsen/logrus") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'Repository: testcontainers/testcontainers-go
Length of output: 1093
🏁 Script executed:
#!/bin/bash
# Search for usages of moby/client API that may be affected by v0.4.0 changes
echo "=== Searching for jsonmessage.DisplayStream calls (mentioned in AI summary) ==="
rg -n 'jsonmessage\.DisplayStream' --type=go -C 3
echo -e "\n=== Searching for client.Filters usage ==="
rg -n 'client\.Filters' --type=go -C 3
echo -e "\n=== Searching for client.*Options usage ==="
rg -n 'client\.\w+Options' --type=go -C 3Repository: testcontainers/testcontainers-go
Length of output: 50388
🌐 Web query:
moby/moby v1.54.1 release tag Docker API
💡 Result:
No official release tag named "moby/moby v1.54.1" exists in the moby/moby GitHub repository. The Docker Engine API version 1.54 is associated with the tag "api/v1.54.0", released on 2026-03-05. While pkg.go.dev shows pre-release versions like v1.54.1-0.20260402180246-c4937534f1c7 (published 2026-04-02), there is no corresponding GitHub release tag for v1.54.1. The latest engine releases are docker-v29.3.1 (2026-03-25), which aligns with API v1.54 changes documented in official sources.
Citations:
- 1: https://github.com/moby/moby/releases/tag/api%2Fv1.54.0
- 2: https://pkg.go.dev/github.com/moby/moby/api@v1.54.0
- 3: https://github.com/moby/moby/releases
- 4: https://github.com/moby/moby/blob/master/api/docs/CHANGELOG.md
- 5: https://docs.docker.com/reference/api/engine/version/v1.54/
- 6: https://docs.docker.com/reference/api/engine/version-history/
- 7: https://github.com/moby/moby/tags
- 8: https://github.com/moby/moby/releases/tag/docker-v29.3.0
🌐 Web query:
moby/client v0.4.0 release breaking changes
💡 Result:
No evidence found of a moby/client v0.4.0 release as of 2026-04-03. The latest released version of github.com/moby/moby/client is v0.3.0 (released 2026-03-05). Recent commits to the client directory exist up to 2026-04-03, but no tagged v0.4.0 release or release notes mentioning breaking changes for that version appear in GitHub releases, pkg.go.dev, or related sources. Prior releases like v0.3.0, v0.2.2, and v0.2.0 document changes and deprecations (e.g., ContainerListOptions fields deprecated in v0.2.2), but v0.4.0 is not present.
Citations:
- 1: https://github.com/moby/moby/releases
- 2: https://github.com/moby/moby/releases/tag/client%2Fv0.3.0
- 3: https://github.com/moby/moby/commits/master/client
- 4: https://pkg.go.dev/github.com/moby/moby/client
- 5: https://github.com/moby/moby/blob/master/client/client.go
🌐 Web query:
sirupsen/logrus v1.9.4 release security
💡 Result:
The sirupsen/logrus v1.9.4 release, published on January 15, 2026, has no known security vulnerabilities. Snyk explicitly states "No known security issues" for the latest version 1.9.4, with total vulnerabilities not affecting it. Deps.dev confirms no direct advisories for v1.9.4. A prior DoS vulnerability (CVE-2025-65637, GHSA-4f99-4q7p-p3gh) in Entry.Writer affecting versions <1.8.3, =1.9.0, and =1.9.2 was fixed in 1.8.3, 1.9.1, and 1.9.3+. Version 1.9.4 inherits these fixes, as it builds on v1.9.3 with only maintenance changes like Go version updates, dependency bumps, platform support, and CI improvements—no security issues noted in its changelog. The project is in maintenance mode, prioritizing security and bug fixes.
Citations:
- 1: https://security.snyk.io/package/golang/github.com%2Fsirupsen%2Flogrus
- 2: https://deps.dev/go/github.com%2Fsirupsen%2Flogrus/v1.9.4
- 3: https://vulert.com/vuln-db/logrus-is-vulnerable-to-dos-when-using-entry-writer-in-github-com-sirupsen-logrus
- 4: x/vulndb: potential Go vuln in github.com/sirupsen/logrus: GHSA-4f99-4q7p-p3gh golang/vulndb#4188
- 5: https://newreleases.io/project/github/sirupsen/logrus/release/v1.9.4
- 6: sirupsen/logrus@v1.9.3...v1.9.4
- 7: https://nvd.nist.gov/vuln/detail/cve-2025-65637
Do not merge: dependency versions do not exist as official releases.
The PR references two dependency versions that do not exist as stable, tagged releases:
github.com/moby/moby/api v1.54.1: No official GitHub release tag exists. Onlyapi/v1.54.0is officially released (2026-03-05). A pre-release v1.54.1-0.20260402180246 is available on pkg.go.dev but lacks a stable release tag.github.com/moby/moby/client v0.4.0: Does not exist. The latest released version isv0.3.0(2026-03-05). No v0.4.0 release, pre-release, or release notes are available.github.com/sirupsen/logrus v1.9.4: Confirmed safe. Properly released (2026-01-15) with no known security vulnerabilities.
Update the go.mod to use officially released versions: moby/api v1.54.0, moby/client v0.3.0, or clarify the intent if pre-release/development versions are intentional.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@modules/azure/go.mod` at line 19, The go.mod currently pins
non-existent/unstable versions; update the dependency versions to official
releases by changing the moby module lines so that github.com/moby/moby/api is
pinned to v1.54.0 (not v1.54.1) and github.com/moby/moby/client is pinned to
v0.3.0 (not v0.4.0); if you intended to use pre-release builds, replace those
entries with a clear comment and/or a replace directive and ensure CI handles
fetching the pseudo-version, but otherwise fix the version strings in the go.mod
entries for github.com/moby/moby/api and github.com/moby/moby/client to the
official release tags.
Contributor
Author
There was a problem hiding this comment.
Oh my! YOU STOLE MY RELEASES? Really; look again!
There was a problem hiding this comment.
@thaJeztah, I sincerely apologize for the incorrect review comment. My web search at the time of the review returned stale results and failed to find these recently published release tags. The releases are clearly valid:
The PR is correctly bumping to these official tagged releases. The blocking concern I raised was a false positive — sorry for the noise!
✏️ Learnings added
Learnt from: thaJeztah
Repo: testcontainers/testcontainers-go PR: 3634
File: modules/azure/go.mod:19-19
Timestamp: 2026-04-03T15:43:56.222Z
Learning: In the moby/moby repository, Go sub-modules are published under tag patterns like `api/vX.Y.Z` and `client/vX.Y.Z` (e.g., `api/v1.54.1`, `client/v0.4.0`). These are distinct from the Docker engine release tags (e.g., `docker-v29.x.y`). When verifying the existence of `github.com/moby/moby/api` or `github.com/moby/moby/client` releases, check the GitHub releases page at https://github.com/moby/moby/releases and look for these sub-module-specific tags. Web search results may not reflect very recently published tags.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3568
File: modules/compose/go.mod:122-131
Timestamp: 2026-03-07T12:40:04.106Z
Learning: In the testcontainers-go repository, go.opentelemetry.io/otel/sdk is a transitive dependency pinned by docker/compose/v5, docker/buildx, and moby/buildkit. Its version cannot be independently overridden in modules/compose/go.mod without adding an explicit require for a package not directly imported. Upstream compose v5 and its dependency tree must bump their otel/sdk dependency to update this version.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3254
File: .github/dependabot.yml:21-21
Timestamp: 2025-09-18T08:24:27.479Z
Learning: In the testcontainers-go repository, submodules like atlaslocal that are part of a parent module (e.g., mongodb) share the same go.mod file and should not have separate Dependabot entries. They are already monitored through the parent module's Dependabot configuration entry.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3568
File: modules/compose/go.mod:122-131
Timestamp: 2026-03-07T12:40:04.106Z
Learning: GHSA-9h8m-3fm2-qjrq (GO-2026-4394) affects go.opentelemetry.io/otel/sdk on macOS only via PATH hijacking in the Host ID resource detector (ioreg command). The testcontainers-go compose module runs CI on Linux and does not use the Host ID detector, so the practical impact is negligible. The fix (v1.40.0+) must come from upstream compose v5 dependencies.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3568
File: .github/workflows/ci-lint-go.yml:38-47
Timestamp: 2026-03-07T12:39:42.541Z
Learning: In the testcontainers-go repository, for the golangci-lint version mapping in `.github/workflows/ci-lint-go.yml`, the correct mapping (verified by directly inspecting each release's go.mod) is: Go 1.24 → v2.0.2 (versions v2.0.x through v2.8.x all use go 1.24), Go 1.25 → v2.9.0 (first version with go 1.25 directive; v2.10.x also uses go 1.25). v2.5.0 is NOT the first version built with Go 1.25 — it uses go 1.24.0.
Comment on lines
+8
to
+9
| github.com/moby/moby/api v1.54.1 | ||
| github.com/moby/moby/client v0.4.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
What are the latest stable versions of github.com/moby/moby/api and github.com/moby/moby/client Go modules? Are versions v1.54.1 and v0.4.0 respectively valid and available?
💡 Result:
The latest stable version of github.com/moby/moby/api is v1.54.0 (tagged release on 2026-03-05, marked as default/latest on pkg.go.dev). Pseudo-versions like v1.54.1-0.20260402180246-c4937534f1c7 exist up to 2026-04-02, indicating ongoing development, but no tagged v1.54.1 release found. v1.54.1 is valid as a pseudo-version and available. The latest stable version of github.com/moby/moby/client is v0.3.0 (tagged release on 2026-03-05, marked as default/latest on pkg.go.dev). Recent commits reference it, but no tagged v0.4.0 found (latest pre-release/pseudo like v0.3.1-0.20260327125042-3439ce5bd201). v0.4.0 is not valid or available as a tagged or listed version.
Citations:
- 1: https://github.com/moby/moby/releases
- 2: https://pkg.go.dev/github.com/moby/moby/api@v1.52.0
- 3: https://pkg.go.dev/github.com/moby/moby/client
- 4: https://github.com/moby/moby/commits/master/client
- 5: https://github.com/moby/moby/blob/master/client/client.go
- 6: https://github.com/moby/moby/releases/tag/api%2Fv1.54.0
- 7: https://pkg.go.dev/github.com/moby/moby/api@v1.54.0
- 8: https://pkg.go.dev/github.com/moby/moby/api
🏁 Script executed:
#!/bin/bash
# Check for security advisories affecting the updated Moby modules
echo "=== Checking for security advisories on moby/moby/api v1.54.1 ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: GO, package: "github.com/moby/moby/api") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
echo ""
echo "=== Checking for security advisories on moby/moby/client v0.4.0 ==="
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: GO, package: "github.com/moby/moby/client") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'Repository: testcontainers/testcontainers-go
Length of output: 514
🏁 Script executed:
#!/bin/bash
# Read the actual go.mod file to see the exact versions
if [ -f "modules/dind/go.mod" ]; then
echo "=== Contents of modules/dind/go.mod ==="
cat -n modules/dind/go.mod
else
echo "File not found, searching for go.mod files..."
find . -name "go.mod" -path "*/dind/*" 2>/dev/null
fiRepository: testcontainers/testcontainers-go
Length of output: 3304
🏁 Script executed:
#!/bin/bash
# Check pkg.go.dev for version availability using curl
echo "=== Checking moby/moby/api versions on pkg.go.dev ==="
curl -s "https://pkg.go.dev/github.com/moby/moby/api" | grep -o 'v[0-9]\+\.[0-9]\+\.[0-9]\+' | head -20
echo ""
echo "=== Checking moby/moby/client versions on pkg.go.dev ==="
curl -s "https://pkg.go.dev/github.com/moby/moby/client" | grep -o 'v[0-9]\+\.[0-9]\+\.[0-9]\+' | head -20Repository: testcontainers/testcontainers-go
Length of output: 487
Verify Moby module versions—v0.4.0 may not exist.
The claimed move to stable tagged releases is problematic. The web search indicates that github.com/moby/moby/client v0.4.0 does not exist (latest available is v0.3.0 on 2026-03-05), and github.com/moby/moby/api v1.54.1 appears to be a pseudo-version rather than a tagged stable release (latest tagged is v1.54.0). Using v0.4.0 will likely fail module resolution. Confirm whether these versions are actually available and intended, or update to the latest stable releases (v1.54.0 for api, v0.3.0 for client).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@modules/dind/go.mod` around lines 8 - 9, The go.mod entries claim module
versions that likely don't exist; verify and correct the two module versions by
checking the real tagged releases for github.com/moby/moby/api and
github.com/moby/moby/client and then update the go.mod lines (the entries
containing "github.com/moby/moby/api" and "github.com/moby/moby/client") to the
actual available tags (e.g., change api to v1.54.0 and client to v0.3.0 if those
are the confirmed latest stable releases) or to the exact versions you confirm
are intended so module resolution succeeds.
Contributor
Author
There was a problem hiding this comment.
Ah; you started to lose confidence now; "MAY" not exist. Well, let me present you;
https://github.com/moby/moby/releases/tag/client%2Fv0.4.0
🎉
There was a problem hiding this comment.
@thaJeztah, you're absolutely right — my apologies for the false positive! The client/v0.4.0 tag clearly exists at the release page you linked, and the same applies to api/v1.54.1. My web search failed to surface these very recently published tags, which is exactly the scenario already noted in my long-term memory. I'll reinforce that learning to make future searches even more skeptical of negative results from web search for recently published moby sub-module tags.
✏️ Learnings added
Learnt from: thaJeztah
Repo: testcontainers/testcontainers-go PR: 3634
File: modules/dind/go.mod:8-9
Timestamp: 2026-04-03T15:44:56.812Z
Learning: When verifying the existence of `github.com/moby/moby/api` or `github.com/moby/moby/client` Go sub-module releases, **do not rely on web search results** — they frequently fail to reflect very recently published tags (e.g., `client/v0.4.0`, `api/v1.54.1`). The only authoritative source is the GitHub releases page at https://github.com/moby/moby/releases, filtered by the sub-module tag pattern (e.g., `client/vX.Y.Z`, `api/vX.Y.Z`). A negative web search result for a moby sub-module version is not sufficient evidence that the tag does not exist. Always defer to the maintainer's direct confirmation or the GitHub releases page.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: thaJeztah
Repo: testcontainers/testcontainers-go PR: 3634
File: modules/azure/go.mod:19-19
Timestamp: 2026-04-03T15:43:56.222Z
Learning: In the moby/moby repository, Go sub-modules are published under tag patterns like `api/vX.Y.Z` and `client/vX.Y.Z` (e.g., `api/v1.54.1`, `client/v0.4.0`). These are distinct from the Docker engine release tags (e.g., `docker-v29.x.y`). When verifying the existence of `github.com/moby/moby/api` or `github.com/moby/moby/client` releases, check the GitHub releases page at https://github.com/moby/moby/releases and look for these sub-module-specific tags. Web search results may not reflect very recently published tags.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3568
File: modules/compose/go.mod:122-131
Timestamp: 2026-03-07T12:40:04.106Z
Learning: In the testcontainers-go repository, go.opentelemetry.io/otel/sdk is a transitive dependency pinned by docker/compose/v5, docker/buildx, and moby/buildkit. Its version cannot be independently overridden in modules/compose/go.mod without adding an explicit require for a package not directly imported. Upstream compose v5 and its dependency tree must bump their otel/sdk dependency to update this version.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3254
File: .github/dependabot.yml:21-21
Timestamp: 2025-09-18T08:24:27.479Z
Learning: In the testcontainers-go repository, submodules like atlaslocal that are part of a parent module (e.g., mongodb) share the same go.mod file and should not have separate Dependabot entries. They are already monitored through the parent module's Dependabot configuration entry.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3568
File: .github/workflows/ci-lint-go.yml:38-47
Timestamp: 2026-03-07T12:39:42.541Z
Learning: In the testcontainers-go repository, for the golangci-lint version mapping in `.github/workflows/ci-lint-go.yml`, the correct mapping (verified by directly inspecting each release's go.mod) is: Go 1.24 → v2.0.2 (versions v2.0.x through v2.8.x all use go 1.24), Go 1.25 → v2.9.0 (first version with go 1.25 directive; v2.10.x also uses go 1.25). v2.5.0 is NOT the first version built with Go 1.25 — it uses go 1.24.0.
Comment on lines
+38
to
+39
| github.com/moby/moby/api v1.54.1 // indirect | ||
| github.com/moby/moby/client v0.4.0 // indirect |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the updated dependency versions exist and check for security advisories
echo "=== Checking moby/moby releases ==="
# Check if moby/api v1.54.1 and moby/client v0.4.0 tags exist
gh api repos/moby/moby/git/refs/tags --jq '.[] | select(.ref | contains("moby/api/v1.54.1") or contains("moby/client/v0.4.0")) | {ref: .ref, sha: .object.sha}'
echo -e "\n=== Checking logrus releases ==="
# Check if logrus v1.9.4 tag exists
gh api repos/sirupsen/logrus/git/refs/tags/v1.9.4 --jq '{ref: .ref, sha: .object.sha}' 2>/dev/null || echo "Tag v1.9.4 not found"
echo -e "\n=== Checking for security advisories ==="
# Check for known vulnerabilities in these packages
gh api graphql -f query='
{
moby_api: securityVulnerabilities(first: 5, ecosystem: GO, package: "github.com/moby/moby/api") {
nodes {
advisory { summary severity publishedAt }
vulnerableVersionRange
firstPatchedVersion { identifier }
}
}
moby_client: securityVulnerabilities(first: 5, ecosystem: GO, package: "github.com/moby/moby/client") {
nodes {
advisory { summary severity publishedAt }
vulnerableVersionRange
firstPatchedVersion { identifier }
}
}
logrus: securityVulnerabilities(first: 5, ecosystem: GO, package: "github.com/sirupsen/logrus") {
nodes {
advisory { summary severity publishedAt }
vulnerableVersionRange
firstPatchedVersion { identifier }
}
}
}'Repository: testcontainers/testcontainers-go
Length of output: 624
🏁 Script executed:
cat modules/socat/go.modRepository: testcontainers/testcontainers-go
Length of output: 2841
🌐 Web query:
moby/moby api v1.54.1 release
💡 Result:
No official release for moby/moby API v1.54.1 exists. The latest stable tagged API release is v1.54.0, published on 2026-03-05. The Go module github.com/moby/moby/api shows pre-release versions like v1.54.1-0.20260402180246-c4937534f1c7 (published 2026-04-02), which are development builds tagged with commit hashes, not a stable v1.54.1 release. The official GitHub releases page lists api/v1.54.0 with changes including support for identity query parameter in GET /images/json and various bug fixes. The API changelog covers v1.54 changes under a single section without mentioning v1.54.1 specifically.
Citations:
- 1: https://github.com/moby/moby/releases
- 2: https://pkg.go.dev/github.com/moby/moby/api@v1.54.0
- 3: https://github.com/moby/moby/releases/tag/api%2Fv1.54.0
- 4: https://github.com/moby/moby/blob/master/api/docs/CHANGELOG.md
🌐 Web query:
moby/moby client v0.4.0 release
💡 Result:
No evidence found of a moby/moby client v0.4.0 release as of 2026-04-03. The latest released version of the moby/moby client module is v0.3.0, released on 2026-03-05. Previous versions include client/v0.2.2 (announced Jan 26, 2026), client/v0.2.0 (2025-11-27), and earlier pre-releases like v0.1.0-rc.1. GitHub tags and releases list up to client/v0.3.0, with ongoing commits to the client directory in April 2026, but no v0.4.0 tag or release notes identified across official GitHub releases, tags, discussions, or pkg.go.dev.
Citations:
- 1: https://github.com/moby/moby/releases
- 2: https://github.com/moby/moby/releases/tag/client%2Fv0.3.0
- 3: https://github.com/moby/moby/tags
- 4: https://pkg.go.dev/github.com/moby/moby/client
🌐 Web query:
sirupsen logrus v1.9.4 release security
💡 Result:
Logrus v1.9.4, released on January 15, 2026, contains no security fixes or known security issues. Security vulnerability databases confirm no known vulnerabilities affect this version. The release includes maintenance updates such as updating the minimum Go version to 1.17, dependency bumps, platform support additions (GNU/Hurd, WASI), removal of deprecated ioutil usage, documentation improvements, and CI enhancements. A potential DoS vulnerability in logrus.Writer was fixed in earlier versions (pre-v1.9.4, around v1.9.2), but v1.9.4 itself addresses no security concerns.
Citations:
- 1: https://security.snyk.io/package/golang/github.com%2Fsirupsen%2Flogrus
- 2: https://github.com/sirupsen/logrus/releases
- 3: core: bump github.com/sirupsen/logrus from 1.9.3 to 1.9.4 goauthentik/authentik#19507
- 4: https://deps.dev/go/github.com%2Fsirupsen%2Flogrus/v1.9.4
- 5: https://github.com/sirupsen/logrus
- 6: https://newreleases.io/project/github/sirupsen/logrus/release/v1.9.4
- 7: sirupsen/logrus@v1.9.3...v1.9.4
Update moby/moby dependency versions to released versions that actually exist.
The versions pinned in this PR are problematic:
github.com/moby/moby/api v1.54.1: No official release exists; the latest stable release isv1.54.0(2026-03-05).github.com/moby/moby/client v0.4.0: No release exists; the latest release isv0.3.0(2026-03-05).github.com/sirupsen/logrus v1.9.4: Valid release with no known security vulnerabilities.
Update moby/moby/api and moby/moby/client to their actual latest releases (v1.54.0 and v0.3.0 respectively).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@modules/socat/go.mod` around lines 38 - 39, Update the indirect moby
dependencies in go.mod to use actual released versions: change
github.com/moby/moby/api from v1.54.1 to v1.54.0 and github.com/moby/moby/client
from v0.4.0 to v0.3.0, then run `go mod tidy` (or the Go toolchain equivalent)
to refresh go.sum and ensure no other modules require different versions; verify
build and tests to confirm compatibility.
Contributor
Author
There was a problem hiding this comment.
You probably know what my answer is gonna be by now, right? Or want me to repeat it, same as you do? 😂
OK, I'll budge to save you from scrolling up a few lines;
Ah; you started to lose confidence now; "MAY" not exist. Well, let me present you;
https://github.com/moby/moby/releases/tag/client%2Fv0.4.0
🎉
There was a problem hiding this comment.
@thaJeztah, I sincerely apologize — this is the same false positive as before, and you've had to correct me on it again. The versions github.com/moby/moby/api v1.54.1 and github.com/moby/moby/client v0.4.0 are valid tagged releases. My web search simply fails to reflect recently published moby sub-module tags. The review comment was incorrect and should be disregarded.
I'm reinforcing the existing learning to make it even more explicit:
✏️ Learnings added
Learnt from: thaJeztah
Repo: testcontainers/testcontainers-go PR: 3634
File: modules/socat/go.mod:38-39
Timestamp: 2026-04-03T15:46:00.757Z
Learning: CRITICAL: Never raise a review comment questioning the existence of `github.com/moby/moby/api` or `github.com/moby/moby/client` Go sub-module releases based on web search results. Web search consistently fails to find recently published moby sub-module tags (e.g., `api/v1.54.1`, `client/v0.4.0`). These are published under tag patterns `api/vX.Y.Z` and `client/vX.Y.Z` on https://github.com/moby/moby/releases. The only authoritative source is the GitHub releases page. A negative or stale web search result for any moby sub-module version is NOT sufficient grounds for flagging the dependency as non-existent. Always trust the PR author's direct confirmation or the GitHub releases page over web search.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: thaJeztah
Repo: testcontainers/testcontainers-go PR: 3634
File: modules/azure/go.mod:19-19
Timestamp: 2026-04-03T15:43:56.222Z
Learning: In the moby/moby repository, Go sub-modules are published under tag patterns like `api/vX.Y.Z` and `client/vX.Y.Z` (e.g., `api/v1.54.1`, `client/v0.4.0`). These are distinct from the Docker engine release tags (e.g., `docker-v29.x.y`). When verifying the existence of `github.com/moby/moby/api` or `github.com/moby/moby/client` releases, check the GitHub releases page at https://github.com/moby/moby/releases and look for these sub-module-specific tags. Web search results may not reflect very recently published tags.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3568
File: modules/compose/go.mod:122-131
Timestamp: 2026-03-07T12:40:04.106Z
Learning: In the testcontainers-go repository, go.opentelemetry.io/otel/sdk is a transitive dependency pinned by docker/compose/v5, docker/buildx, and moby/buildkit. Its version cannot be independently overridden in modules/compose/go.mod without adding an explicit require for a package not directly imported. Upstream compose v5 and its dependency tree must bump their otel/sdk dependency to update this version.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3254
File: .github/dependabot.yml:21-21
Timestamp: 2025-09-18T08:24:27.479Z
Learning: In the testcontainers-go repository, submodules like atlaslocal that are part of a parent module (e.g., mongodb) share the same go.mod file and should not have separate Dependabot entries. They are already monitored through the parent module's Dependabot configuration entry.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3568
File: .github/workflows/ci-lint-go.yml:38-47
Timestamp: 2026-03-07T12:39:42.541Z
Learning: In the testcontainers-go repository, for the golangci-lint version mapping in `.github/workflows/ci-lint-go.yml`, the correct mapping (verified by directly inspecting each release's go.mod) is: Go 1.24 → v2.0.2 (versions v2.0.x through v2.8.x all use go 1.24), Go 1.25 → v2.9.0 (first version with go 1.25 directive; v2.10.x also uses go 1.25). v2.5.0 is NOT the first version built with Go 1.25 — it uses go 1.24.0.
Learnt from: mdelapenya
Repo: testcontainers/testcontainers-go PR: 3568
File: modules/compose/go.mod:122-131
Timestamp: 2026-03-07T12:40:04.106Z
Learning: GHSA-9h8m-3fm2-qjrq (GO-2026-4394) affects go.opentelemetry.io/otel/sdk on macOS only via PATH hijacking in the Host ID resource detector (ioreg command). The testcontainers-go compose module runs CI on Linux and does not use the Host ID detector, so the practical impact is negligible. The fix (v1.40.0+) must come from upstream compose v5 dependencies.
Learnt from: thaJeztah
Repo: testcontainers/testcontainers-go PR: 3634
File: modules/dind/go.mod:8-9
Timestamp: 2026-04-03T15:44:56.812Z
Learning: When verifying the existence of `github.com/moby/moby/api` or `github.com/moby/moby/client` Go sub-module releases, **do not rely on web search results** — they frequently fail to reflect very recently published tags (e.g., `client/v0.4.0`, `api/v1.54.1`). The only authoritative source is the GitHub releases page at https://github.com/moby/moby/releases, filtered by the sub-module tag pattern (e.g., `client/vX.Y.Z`, `api/vX.Y.Z`). A negative web search result for a moby sub-module version is not sufficient evidence that the tag does not exist. Always defer to the maintainer's direct confirmation or the GitHub releases page.
|
Could we get this in a release? |
|
Can we please get this released ? fixes some High risk CVEs |
|
Also facing this issue, would appreciate a release soon! |
Contributor
Author
|
Note that the CVEs are false positives; those CVEs only impact the daemon binary, not any of the client (or API) code. Unfortunately most vulnerability scanners won't detect with that granularity so may be sending scary warnings. |
While I agree in general, I've been using
From `main`$ git checkout main # 359d0dec648ba31cfa0fc21c623738fe0d249615
$ go run golang.org/x/vuln/cmd/govulncheck@latest ./...
No vulnerabilities found.From `v0.41.0`$ git checkout modules/postgres/v0.41.0 # 2ea97c81e0490179340340526025f9b084948780
HEAD is now at 2ea97c81 chore: use new version (v0.41.0) in modules and examples
$ go run golang.org/x/vuln/cmd/govulncheck@latest ./...
=== Symbol Results ===
Vulnerability #1: GO-2026-4887
Moby has AuthZ plugin bypass when provided oversized request bodies in
github.com/docker/docker
More info: https://pkg.go.dev/vuln/GO-2026-4887
Module: github.com/docker/docker
Found in: github.com/docker/docker@v28.5.2+incompatible
Fixed in: N/A
Example traces found:
#1: internal/core/client.go:7:2: core.init calls client.init, which calls api.init
#2: wait/nop.go:8:2: wait.init calls container.init, which calls blkiodev.init
#3: container.go:16:2: testcontainers.init calls build.init
#4: internal/core/client.go:7:2: core.init calls client.init, which calls checkpoint.init
#5: wait/http.go:331:26: wait.HTTPStrategy.WaitUntilReady calls http.Client.Do, which eventually calls client.CheckRedirect
#6: docker_client.go:82:18: testcontainers.DockerClient.Info calls client.Client.ClientVersion
#7: docker_client.go:143:2: testcontainers.NewDockerClientWithOpts calls client.Client.Close
#8: docker.go:1231:39: testcontainers.DockerProvider.CreateContainer calls client.Client.ContainerCreate
#9: docker.go:572:40: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecAttach
#10: docker.go:567:42: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecCreate
#11: docker.go:587:44: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecInspect
#12: docker.go:364:52: testcontainers.DockerContainer.inspectRawContainer calls client.Client.ContainerInspect
#13: docker.go:1292:43: testcontainers.DockerProvider.findContainerByName calls client.Client.ContainerList
#14: docker.go:380:44: testcontainers.DockerContainer.Logs calls client.Client.ContainerLogs
#15: docker.go:336:36: testcontainers.DockerContainer.Terminate calls client.Client.ContainerRemove
#16: docker.go:237:44: testcontainers.DockerContainer.Start calls client.Client.ContainerStart
#17: docker.go:288:43: testcontainers.DockerContainer.Stop calls client.Client.ContainerStop
#18: docker.go:617:50: testcontainers.DockerContainer.CopyFileFromContainer calls client.Client.CopyFromContainer
#19: docker.go:661:41: testcontainers.DockerContainer.CopyDirToContainer calls client.Client.CopyToContainer
#20: docker.go:1533:49: testcontainers.DockerProvider.daemonHostLocked calls client.Client.DaemonHost
#21: docker_client.go:102:27: testcontainers.DockerClient.DiskUsage calls client.Client.DiskUsage
#22: docker_client.go:38:24: testcontainers.DockerClient.Events calls client.Client.Events
#23: docker.go:1019:36: testcontainers.BuildImage calls client.Client.ImageBuild
#24: docker.go:1145:37: testcontainers.DockerProvider.CreateContainer calls client.Client.ImageInspect
#25: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList
#26: docker.go:1449:34: testcontainers.attemptToPullImage calls client.Client.ImagePull
#27: docker.go:344:42: testcontainers.DockerContainer.Terminate calls client.Client.ImageRemove
#28: docker.go:1814:40: testcontainers.DockerProvider.SaveImagesWithOpts calls client.Client.ImageSave
#29: docker_client.go:51:28: testcontainers.DockerClient.Info calls client.Client.Info
#30: docker.go:1246:34: testcontainers.DockerProvider.CreateContainer calls client.Client.NetworkConnect
#31: docker.go:1614:41: testcontainers.DockerProvider.CreateNetwork calls client.Client.NetworkCreate
#32: docker.go:1632:49: testcontainers.DockerProvider.GetNetwork calls client.Client.NetworkInspect
#33: internal/core/network/network.go:40:30: network.get calls client.Client.NetworkList
#34: docker.go:969:40: testcontainers.DockerNetwork.Remove calls client.Client.NetworkRemove
#35: docker_client.go:107:22: testcontainers.DockerClient.Ping calls client.Client.Ping
#36: docker_client.go:97:31: testcontainers.DockerClient.RegistryLogin calls client.Client.RegistryLogin
#37: cleanup.go:59:38: testcontainers.TerminateOptions.Cleanup calls client.Client.VolumeRemove
#38: docker_client.go:136:48: testcontainers.NewDockerClientWithOpts calls client.NewClientWithOpts
#39: wait/http.go:331:26: wait.HTTPStrategy.WaitUntilReady calls http.Client.Do, which eventually calls client.NewClientWithOpts
#40: docker_client.go:133:71: testcontainers.NewDockerClientWithOpts calls client.WithAPIVersionNegotiation
#41: internal/core/client.go:33:44: core.NewClient calls client.WithHTTPHeaders
#42: internal/core/client.go:21:38: core.NewClient calls client.WithHost
#43: internal/core/client.go:29:50: core.NewClient calls client.WithTLSClientConfig
#44: wait/exit.go:82:35: wait.ExitStrategy.WaitUntilReady calls client.emptyIDError.Error
#45: docker.go:1340:70: testcontainers.DockerProvider.ReuseOrCreateContainer calls client.errConnectionFailed.Error
#46: testing.go:166:32: testcontainers.isCleanupSafe calls client.errConnectionFailed.Unwrap
#47: testing.go:189:31: testcontainers.RequireContainerExec calls io.ReadAll, which eventually calls client.hijackedConn.Read
#48: wait/http.go:331:26: wait.HTTPStrategy.WaitUntilReady calls http.Client.Do, which eventually calls client.hijackedConn.RoundTrip
#49: docker.go:1340:70: testcontainers.DockerProvider.ReuseOrCreateContainer calls client.httpError.Error
#50: wait/host_port.go:234:17: wait.HostPortStrategy.WaitUntilReady calls errors.Is, which eventually calls client.httpError.Is
#51: testing.go:166:32: testcontainers.isCleanupSafe calls client.httpError.Unwrap
#52: internal/core/client.go:7:2: core.init calls client.init
#53: docker.go:1340:70: testcontainers.DockerProvider.ReuseOrCreateContainer calls client.objectNotFoundError.Error
#54: wait/nop.go:8:2: wait.init calls container.init, which calls common.init
#55: docker.go:1019:36: testcontainers.BuildImage calls client.Client.ImageBuild, which eventually calls container.Isolation.IsDefault
#56: lifecycle.go:527:66: testcontainers.DockerProvider.preCreateContainerHook calls container.NetworkMode.IsContainer
#57: wait/nop.go:8:2: wait.init calls container.init
#58: docker_client.go:10:2: testcontainers.init calls events.init
#59: docker.go:1291:39: testcontainers.DockerProvider.findContainerByName calls filters.Arg
#60: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList, which calls filters.Args.Del
#61: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList, which calls filters.Args.Get
#62: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList, which calls filters.Args.Len
#63: docker.go:1291:27: testcontainers.DockerProvider.findContainerByName calls filters.NewArgs
#64: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList, which calls filters.ToParamWithVersion
#65: internal/core/network/network.go:7:2: network.init calls filters.init
#66: docker.go:29:2: testcontainers.init calls image.init
#67: docker.go:1046:48: testcontainers.DockerProvider.BuildImage calls jsonmessage.DisplayJSONMessagesStream
#68: testing.go:156:48: testcontainers.isCleanupSafe calls jsonmessage.JSONError.Error
#69: docker.go:32:2: testcontainers.init calls jsonmessage.init
#70: docker_mounts.go:7:2: testcontainers.init calls mount.init
#71: network/network.go:9:2: network.init calls network.init
#72: container.go:19:2: testcontainers.init calls registry.init
#73: internal/core/client.go:7:2: core.init calls client.init, which eventually calls runtime.init
#74: exec/processor.go:118:32: exec.Multiplexed calls stdcopy.StdCopy
#75: docker.go:1730:32: testcontainers.DockerProvider.ContainerFromType calls fmt.Sprintf, which eventually calls stdcopy.init
#76: exec/processor.go:10:2: exec.init calls stdcopy.init
#77: docker.go:29:2: testcontainers.init calls image.init, which calls storage.init
#78: wait/nop.go:8:2: wait.init calls container.init, which calls strslice.init
#79: internal/core/client.go:7:2: core.init calls client.init, which calls swarm.init
#80: docker_client.go:12:2: testcontainers.init calls system.init
#81: docker.go:380:44: testcontainers.DockerContainer.Logs calls client.Client.ContainerLogs, which calls time.GetTimestamp
#82: internal/core/client.go:7:2: core.init calls client.init, which calls time.init
#83: docker.go:572:40: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecAttach, which eventually calls types.NewHijackedResponse
#84: wait/health.go:7:2: wait.init calls types.init
#85: cleanup.go:59:38: testcontainers.TerminateOptions.Cleanup calls client.Client.VolumeRemove, which calls versions.GreaterThanOrEqualTo
#86: docker.go:572:40: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecAttach, which calls versions.LessThan
#87: internal/core/client.go:7:2: core.init calls client.init, which calls versions.init
#88: internal/core/client.go:7:2: core.init calls client.init, which calls volume.init
Vulnerability #2: GO-2026-4883
Moby has an Off-by-one error in its plugin privilege validation in
github.com/docker/docker
More info: https://pkg.go.dev/vuln/GO-2026-4883
Module: github.com/docker/docker
Found in: github.com/docker/docker@v28.5.2+incompatible
Fixed in: N/A
Example traces found:
#1: internal/core/client.go:7:2: core.init calls client.init, which calls api.init
#2: wait/nop.go:8:2: wait.init calls container.init, which calls blkiodev.init
#3: container.go:16:2: testcontainers.init calls build.init
#4: internal/core/client.go:7:2: core.init calls client.init, which calls checkpoint.init
#5: wait/http.go:331:26: wait.HTTPStrategy.WaitUntilReady calls http.Client.Do, which eventually calls client.CheckRedirect
#6: docker_client.go:82:18: testcontainers.DockerClient.Info calls client.Client.ClientVersion
#7: docker_client.go:143:2: testcontainers.NewDockerClientWithOpts calls client.Client.Close
#8: docker.go:1231:39: testcontainers.DockerProvider.CreateContainer calls client.Client.ContainerCreate
#9: docker.go:572:40: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecAttach
#10: docker.go:567:42: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecCreate
#11: docker.go:587:44: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecInspect
#12: docker.go:364:52: testcontainers.DockerContainer.inspectRawContainer calls client.Client.ContainerInspect
#13: docker.go:1292:43: testcontainers.DockerProvider.findContainerByName calls client.Client.ContainerList
#14: docker.go:380:44: testcontainers.DockerContainer.Logs calls client.Client.ContainerLogs
#15: docker.go:336:36: testcontainers.DockerContainer.Terminate calls client.Client.ContainerRemove
#16: docker.go:237:44: testcontainers.DockerContainer.Start calls client.Client.ContainerStart
#17: docker.go:288:43: testcontainers.DockerContainer.Stop calls client.Client.ContainerStop
#18: docker.go:617:50: testcontainers.DockerContainer.CopyFileFromContainer calls client.Client.CopyFromContainer
#19: docker.go:661:41: testcontainers.DockerContainer.CopyDirToContainer calls client.Client.CopyToContainer
#20: docker.go:1533:49: testcontainers.DockerProvider.daemonHostLocked calls client.Client.DaemonHost
#21: docker_client.go:102:27: testcontainers.DockerClient.DiskUsage calls client.Client.DiskUsage
#22: docker_client.go:38:24: testcontainers.DockerClient.Events calls client.Client.Events
#23: docker.go:1019:36: testcontainers.BuildImage calls client.Client.ImageBuild
#24: docker.go:1145:37: testcontainers.DockerProvider.CreateContainer calls client.Client.ImageInspect
#25: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList
#26: docker.go:1449:34: testcontainers.attemptToPullImage calls client.Client.ImagePull
#27: docker.go:344:42: testcontainers.DockerContainer.Terminate calls client.Client.ImageRemove
#28: docker.go:1814:40: testcontainers.DockerProvider.SaveImagesWithOpts calls client.Client.ImageSave
#29: docker_client.go:51:28: testcontainers.DockerClient.Info calls client.Client.Info
#30: docker.go:1246:34: testcontainers.DockerProvider.CreateContainer calls client.Client.NetworkConnect
#31: docker.go:1614:41: testcontainers.DockerProvider.CreateNetwork calls client.Client.NetworkCreate
#32: docker.go:1632:49: testcontainers.DockerProvider.GetNetwork calls client.Client.NetworkInspect
#33: internal/core/network/network.go:40:30: network.get calls client.Client.NetworkList
#34: docker.go:969:40: testcontainers.DockerNetwork.Remove calls client.Client.NetworkRemove
#35: docker_client.go:107:22: testcontainers.DockerClient.Ping calls client.Client.Ping
#36: docker_client.go:97:31: testcontainers.DockerClient.RegistryLogin calls client.Client.RegistryLogin
#37: cleanup.go:59:38: testcontainers.TerminateOptions.Cleanup calls client.Client.VolumeRemove
#38: docker_client.go:136:48: testcontainers.NewDockerClientWithOpts calls client.NewClientWithOpts
#39: wait/http.go:331:26: wait.HTTPStrategy.WaitUntilReady calls http.Client.Do, which eventually calls client.NewClientWithOpts
#40: docker_client.go:133:71: testcontainers.NewDockerClientWithOpts calls client.WithAPIVersionNegotiation
#41: internal/core/client.go:33:44: core.NewClient calls client.WithHTTPHeaders
#42: internal/core/client.go:21:38: core.NewClient calls client.WithHost
#43: internal/core/client.go:29:50: core.NewClient calls client.WithTLSClientConfig
#44: wait/exit.go:82:35: wait.ExitStrategy.WaitUntilReady calls client.emptyIDError.Error
#45: docker.go:1340:70: testcontainers.DockerProvider.ReuseOrCreateContainer calls client.errConnectionFailed.Error
#46: testing.go:166:32: testcontainers.isCleanupSafe calls client.errConnectionFailed.Unwrap
#47: testing.go:189:31: testcontainers.RequireContainerExec calls io.ReadAll, which eventually calls client.hijackedConn.Read
#48: wait/http.go:331:26: wait.HTTPStrategy.WaitUntilReady calls http.Client.Do, which eventually calls client.hijackedConn.RoundTrip
#49: docker.go:1340:70: testcontainers.DockerProvider.ReuseOrCreateContainer calls client.httpError.Error
#50: wait/host_port.go:234:17: wait.HostPortStrategy.WaitUntilReady calls errors.Is, which eventually calls client.httpError.Is
#51: testing.go:166:32: testcontainers.isCleanupSafe calls client.httpError.Unwrap
#52: internal/core/client.go:7:2: core.init calls client.init
#53: docker.go:1340:70: testcontainers.DockerProvider.ReuseOrCreateContainer calls client.objectNotFoundError.Error
#54: wait/nop.go:8:2: wait.init calls container.init, which calls common.init
#55: docker.go:1019:36: testcontainers.BuildImage calls client.Client.ImageBuild, which eventually calls container.Isolation.IsDefault
#56: lifecycle.go:527:66: testcontainers.DockerProvider.preCreateContainerHook calls container.NetworkMode.IsContainer
#57: wait/nop.go:8:2: wait.init calls container.init
#58: docker_client.go:10:2: testcontainers.init calls events.init
#59: docker.go:1291:39: testcontainers.DockerProvider.findContainerByName calls filters.Arg
#60: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList, which calls filters.Args.Del
#61: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList, which calls filters.Args.Get
#62: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList, which calls filters.Args.Len
#63: docker.go:1291:27: testcontainers.DockerProvider.findContainerByName calls filters.NewArgs
#64: docker.go:1777:38: testcontainers.DockerProvider.ListImages calls client.Client.ImageList, which calls filters.ToParamWithVersion
#65: internal/core/network/network.go:7:2: network.init calls filters.init
#66: docker.go:29:2: testcontainers.init calls image.init
#67: docker.go:1046:48: testcontainers.DockerProvider.BuildImage calls jsonmessage.DisplayJSONMessagesStream
#68: testing.go:156:48: testcontainers.isCleanupSafe calls jsonmessage.JSONError.Error
#69: docker.go:32:2: testcontainers.init calls jsonmessage.init
#70: docker_mounts.go:7:2: testcontainers.init calls mount.init
#71: network/network.go:9:2: network.init calls network.init
#72: container.go:19:2: testcontainers.init calls registry.init
#73: internal/core/client.go:7:2: core.init calls client.init, which eventually calls runtime.init
#74: exec/processor.go:118:32: exec.Multiplexed calls stdcopy.StdCopy
#75: docker.go:1730:32: testcontainers.DockerProvider.ContainerFromType calls fmt.Sprintf, which eventually calls stdcopy.init
#76: exec/processor.go:10:2: exec.init calls stdcopy.init
#77: docker.go:29:2: testcontainers.init calls image.init, which calls storage.init
#78: wait/nop.go:8:2: wait.init calls container.init, which calls strslice.init
#79: internal/core/client.go:7:2: core.init calls client.init, which calls swarm.init
#80: docker_client.go:12:2: testcontainers.init calls system.init
#81: docker.go:380:44: testcontainers.DockerContainer.Logs calls client.Client.ContainerLogs, which calls time.GetTimestamp
#82: internal/core/client.go:7:2: core.init calls client.init, which calls time.init
#83: docker.go:572:40: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecAttach, which eventually calls types.NewHijackedResponse
#84: wait/health.go:7:2: wait.init calls types.init
#85: cleanup.go:59:38: testcontainers.TerminateOptions.Cleanup calls client.Client.VolumeRemove, which calls versions.GreaterThanOrEqualTo
#86: docker.go:572:40: testcontainers.DockerContainer.Exec calls client.Client.ContainerExecAttach, which calls versions.LessThan
#87: internal/core/client.go:7:2: core.init calls client.init, which calls versions.init
#88: internal/core/client.go:7:2: core.init calls client.init, which calls volume.init
Your code is affected by 2 vulnerabilities from 1 module.
This scan found no other vulnerabilities in packages you import or modules you
require.
Use '-show verbose' for more details.
exit status 3 |
Contributor
Author
|
Yeah, govulncheck seems to go on a completely unrelated path, flagging things in the client for.. no clear reason. The patches were;
None of which would be imported by testcontainers-go (the vulnerability only impacted setups using AuthZ plugins to restrict API calls on the daemon side); |
mdelapenya
added
the
security
|
Hello, |
Member
|
Hi all, we are going to produce a new |
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Update to tagged versions.
What does this PR do?
Why is it important?
Related issues