chore(deps): update docker to v29.4.1

[uniget-bot]

This PR contains the following updates:

Package	Type	Update	Change
docker		patch	29.4.0 → 29.4.1
docker	service-image	patch	29.4.0-dind → 29.4.1-dind
docker	image	patch	29.4.0 → 29.4.1

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

moby/moby (docker)

v29.4.1: v29.4.1

Compare Source

29.4.1

For a full list of pull requests and changes in this release, refer to the relevant GitHub milestones:

• docker/cli, 29.4.1 milestone
• moby/moby, 29.4.1 milestone

Bug fixes and enhancements

• containerd image store: Fix docker image prune --filter label!=key=value incorrectly skipping images that don't have the specified label. moby/moby#52338
• Fix --log-opt "tag={{.ImageID}}" not stripping the digest's algorithm. moby/moby#52343
• Fix intermittent container start failures (EBUSY on secrets/configs remount) on busy Swarm nodes by retrying the read-only remount. moby/moby#52235

Packaging updates

• Update containerd (static binaries only) to v2.2.3. moby/moby#52360
• Update Go runtime to 1.26.2. docker/cli#6920, moby/moby#52329

Networking

• if a container has an IPv4-only or an IPv6-only endpoint with higher "gateway priority" than a dual stack endpoint, the single stack endpoint will now be used as the default gateway for its address family. moby/moby#52328

---

Configuration

📅 Schedule: (in timezone Europe/Berlin)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[nicholasdille-bot]

Auto-approved because label type/renovate is present.

[nicholasdille-bot]

Auto-approved because label type/renovate is present.

[nicholasdille-bot]

Auto-approved because label type/renovate is present.

[github-actions]

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/docker:29.4.1

📦 Image Reference ghcr.io/uniget-org/tools/docker:29.4.1

digest	sha256:3d5678ea9e0b3199b8b0f0afd6d4ca04c4a2982f302d4b526ce8171018e3f8e5
vulnerabilities
platform	linux/amd64
size	106 MB
packages	502

google.golang.org/grpc 1.78.0 (golang) pkg:golang/google.golang.org/grpc@1.78.0 Improper Authorization Affected range <1.79.3 Fixed version 1.79.3 CVSS Score 9.1 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N EPSS Score 0.016% EPSS Percentile 3rd percentile Description Impact What kind of vulnerability is it? Who is impacted? It is an Authorization Bypass resulting from Improper Input Validation of the HTTP/2 :path pseudo-header. The gRPC-Go server was too lenient in its routing logic, accepting requests where the :path omitted the mandatory leading slash (e.g., Service/Method instead of /Service/Method). While the server successfully routed these requests to the correct handler, authorization interceptors (including the official grpc/authz package) evaluated the raw, non-canonical path string. Consequently, "deny" rules defined using canonical paths (starting with /) failed to match the incoming request, allowing it to bypass the policy if a fallback "allow" rule was present. Who is impacted? This affects gRPC-Go servers that meet both of the following criteria: They use path-based authorization interceptors, such as the official RBAC implementation in google.golang.org/grpc/authz or custom interceptors relying on info.FullMethod or grpc.Method(ctx). Their security policy contains specific "deny" rules for canonical paths but allows other requests by default (a fallback "allow" rule). The vulnerability is exploitable by an attacker who can send raw HTTP/2 frames with malformed :path headers directly to the gRPC server. Patches Has the problem been patched? What versions should users upgrade to? Yes, the issue has been patched. The fix ensures that any request with a :path that does not start with a leading slash is immediately rejected with a codes.Unimplemented error, preventing it from reaching authorization interceptors or handlers with a non-canonical path string. Users should upgrade to the following versions (or newer): v1.79.3 The latest master branch. It is recommended that all users employing path-based authorization (especially grpc/authz) upgrade as soon as the patch is available in a tagged release. Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? While upgrading is the most secure and recommended path, users can mitigate the vulnerability using one of the following methods: 1. Use a Validating Interceptor (Recommended Mitigation) Add an "outermost" interceptor to your server that validates the path before any other authorization logic runs: func pathValidationInterceptor(ctx context.Context, req any, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (any, error) { if info.FullMethod == "" || info.FullMethod[0] != '/' { return nil, status.Errorf(codes.Unimplemented, "malformed method name") } return handler(ctx, req) } // Ensure this is the FIRST interceptor in your chain s := grpc.NewServer( grpc.ChainUnaryInterceptor(pathValidationInterceptor, authzInterceptor), ) 2. Infrastructure-Level Normalization If your gRPC server is behind a reverse proxy or load balancer (such as Envoy, NGINX, or an L7 Cloud Load Balancer), ensure it is configured to enforce strict HTTP/2 compliance for pseudo-headers and reject or normalize requests where the :path header does not start with a leading slash. 3. Policy Hardening Switch to a "default deny" posture in your authorization policies (explicitly listing all allowed paths and denying everything else) to reduce the risk of bypasses via malformed inputs.

go.opentelemetry.io/otel/sdk 1.38.0 (golang) pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0 Untrusted Search Path Affected range >=1.15.0 <=1.42.0 Fixed version 1.43.0 CVSS Score 7.3 CVSS Vector CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N EPSS Score 0.006% EPSS Percentile 0th percentile Description Summary The fix for GHSA-9h8m-3fm2-qjrq (CVE-2026-24051) changed the Darwin ioreg command to use an absolute path but left the BSD kenv command using a bare name, allowing the same PATH hijacking attack on BSD and Solaris platforms. Root Cause sdk/resource/host_id.go line 42: if result, err := r.execCommand("kenv", "-q", "smbios.system.uuid"); err == nil { Compare with the fixed Darwin path at line 58: result, err := r.execCommand("/usr/sbin/ioreg", "-rd1", "-c", "IOPlatformExpertDevice") The execCommand helper at sdk/resource/host_id_exec.go uses exec.Command(name, arg...) which searches $PATH when the command name contains no path separator. Affected platforms (per build tag in host_id_bsd.go:4): DragonFly BSD, FreeBSD, NetBSD, OpenBSD, Solaris. The kenv path is reached when /etc/hostid does not exist (line 38-40), which is common on FreeBSD systems. Attack Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk Attacker places a malicious kenv binary earlier in $PATH Application initializes OpenTelemetry resource detection at startup hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary Arbitrary code executes in the context of the application Same attack vector and impact as CVE-2026-24051. Suggested Fix Use the absolute path: if result, err := r.execCommand("/bin/kenv", "-q", "smbios.system.uuid"); err == nil { On FreeBSD, kenv is located at /bin/kenv. Untrusted Search Path Affected range >=1.21.0 <1.40.0 Fixed version 1.40.0 CVSS Score 7 CVSS Vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H EPSS Score 0.011% EPSS Percentile 1st percentile Description Impact The OpenTelemetry Go SDK in version v1.20.0-1.39.0 is vulnerable to Path Hijacking (Untrusted Search Paths) on macOS/Darwin systems. The resource detection code in sdk/resource/host_id.go executes the ioreg system command using a search path. An attacker with the ability to locally modify the PATH environment variable can achieve Arbitrary Code Execution (ACE) within the context of the application. Patches This has been patched in d45961b, which was released with v1.40.0. References CWE-426: Untrusted Search Path

github.com/go-jose/go-jose/v4 4.1.3 (golang) pkg:golang/github.com/go-jose/go-jose@4.1.3#v4 Uncaught Exception Affected range <4.1.4 Fixed version 4.1.4 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.019% EPSS Percentile 5th percentile Description Impact Decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key. This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected. This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common. Panics can lead to denial of service. Fixed In 4.1.4 and v3.0.5 Workarounds If the list of keyAlgorithms passed to ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() does not include key wrapping algorithms (those ending in KW), your application is unaffected. If your application uses key wrapping, you can prevalidate to the JWE objects to ensure the encrypted_key field is nonempty. If your application accepts JWE Compact Serialization, apply that validation to the corresponding field of that serialization (the data between the first and second .). Thanks Thanks to Datadog's Security team for finding this issue.

golang.org/x/net 0.35.0 (golang) pkg:golang/golang.org/x/net@0.35.0 Affected range <0.45.0 Fixed version 0.45.0 EPSS Score 0.011% EPSS Percentile 1st percentile Description The html.Parse function in golang.org/x/net/html has an infinite parsing loop when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content. Affected range <0.45.0 Fixed version 0.45.0 EPSS Score 0.017% EPSS Percentile 4th percentile Description The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content. Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Affected range <0.38.0 Fixed version 0.38.0 CVSS Score 5.3 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N EPSS Score 0.119% EPSS Percentile 31st percentile Description The tokenizer incorrectly interprets tags with unquoted attribute values that end with a solidus character (/) as self-closing. When directly using Tokenizer, this can result in such tags incorrectly being marked as self-closing, and when using the Parse functions, this can result in content following such tags as being placed in the wrong scope during DOM construction, but only when tags are in foreign content (e.g. , , etc contexts). Misinterpretation of Input Affected range <0.36.0 Fixed version 0.36.0 CVSS Score 4.4 CVSS Vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:L EPSS Score 0.023% EPSS Percentile 6th percentile Description Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.

golang.org/x/net 0.43.0 (golang) pkg:golang/golang.org/x/net@0.43.0 Affected range <0.45.0 Fixed version 0.45.0 EPSS Score 0.011% EPSS Percentile 1st percentile Description The html.Parse function in golang.org/x/net/html has an infinite parsing loop when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content. Affected range <0.45.0 Fixed version 0.45.0 EPSS Score 0.017% EPSS Percentile 4th percentile Description The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.

go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp 1.35.0 (golang) pkg:golang/go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp@1.35.0 Memory Allocation with Excessive Size Value Affected range <1.43.0 Fixed version 1.43.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.020% EPSS Percentile 5th percentile Description overview: this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer without a size cap. this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection). severity HIGH not claiming: this is a remote dos against every default deployment. claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body. callsite (pinned): exporters/otlp/otlptrace/otlptracehttp/client.go:199 exporters/otlp/otlptrace/otlptracehttp/client.go:230 exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170 exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201 exporters/otlp/otlplog/otlploghttp/client.go:190 exporters/otlp/otlplog/otlploghttp/client.go:221 permalinks (pinned): https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221 root cause: each exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error paths, with no upper bound. impact: a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom). affected component: go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp repro (local-only): unzip poc.zip -d poc cd poc make canonical resp_bytes=33554432 chunk_delay_ms=0 expected output contains: [CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body) [PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512 control (same env, patched target): unzip poc.zip -d poc cd poc make control resp_bytes=33554432 chunk_delay_ms=0 expected control output contains: [CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body) [NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232 attachments: poc.zip (attached) PR_DESCRIPTION.md attack_scenario.md poc.zip Fixed in: open-telemetry/opentelemetry-go#8108

go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp 1.35.0 (golang) pkg:golang/go.opentelemetry.io/otel/exporters@1.35.0#otlp/otlptrace/otlptracehttp Memory Allocation with Excessive Size Value Affected range <1.43.0 Fixed version 1.43.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.020% EPSS Percentile 5th percentile Description overview: this report shows that the otlp HTTP exporters (traces/metrics/logs) read the full HTTP response body into an in-memory bytes.Buffer without a size cap. this is exploitable for memory exhaustion when the configured collector endpoint is attacker-controlled (or a network attacker can mitm the exporter connection). severity HIGH not claiming: this is a remote dos against every default deployment. claiming: if the exporter sends traces to an untrusted collector endpoint (or over a network segment where mitm is realistic), that endpoint can crash the process via a large response body. callsite (pinned): exporters/otlp/otlptrace/otlptracehttp/client.go:199 exporters/otlp/otlptrace/otlptracehttp/client.go:230 exporters/otlp/otlpmetric/otlpmetrichttp/client.go:170 exporters/otlp/otlpmetric/otlpmetrichttp/client.go:201 exporters/otlp/otlplog/otlploghttp/client.go:190 exporters/otlp/otlplog/otlploghttp/client.go:221 permalinks (pinned): https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L199 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlptrace/otlptracehttp/client.go#L230 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L170 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlpmetric/otlpmetrichttp/client.go#L201 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L190 https://github.com/open-telemetry/opentelemetry-go/blob/248da958375e4dfb4a1105645107be3ef04b1c59/exporters/otlp/otlplog/otlploghttp/client.go#L221 root cause: each exporter client reads resp.Body using io.Copy(&respData, resp.Body) into a bytes.Buffer on both success and error paths, with no upper bound. impact: a malicious collector can force large transient heap allocations during export (peak memory scales with attacker-chosen response size) and can potentially crash the instrumented process (oom). affected component: go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp go.opentelemetry.io/otel/exporters/otlp/otlpmetric/otlpmetrichttp go.opentelemetry.io/otel/exporters/otlp/otlplog/otlploghttp repro (local-only): unzip poc.zip -d poc cd poc make canonical resp_bytes=33554432 chunk_delay_ms=0 expected output contains: [CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body) [PROOF_MARKER]: resp_bytes=33554432 peak_alloc_bytes=118050512 control (same env, patched target): unzip poc.zip -d poc cd poc make control resp_bytes=33554432 chunk_delay_ms=0 expected control output contains: [CALLSITE_HIT]: otlptracehttp.UploadTraces::io.Copy(resp.Body) [NC_MARKER]: resp_bytes=33554432 peak_alloc_bytes=512232 attachments: poc.zip (attached) PR_DESCRIPTION.md attack_scenario.md poc.zip Fixed in: open-telemetry/opentelemetry-go#8108