Skip to content

chore(deps): update containerd to v2.2.3#20794

Merged
github-actions[bot] merged 1 commit intomainfrom
renovate/containerd-2.2.x
Apr 15, 2026
Merged

chore(deps): update containerd to v2.2.3#20794
github-actions[bot] merged 1 commit intomainfrom
renovate/containerd-2.2.x

Conversation

@uniget-bot
Copy link
Copy Markdown

This PR contains the following updates:

Package Update Change
containerd patch 2.2.22.2.3

Warning

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


Release Notes

containerd/containerd (containerd)

v2.2.3: containerd 2.2.3

Compare Source

Welcome to the v2.2.3 release of containerd!

The third patch release for containerd 2.2 contains various fixes
and updates including a security patch.

Security Updates
Highlights
Container Runtime Interface (CRI)
  • Preserve cgroup mount options for privileged containers (#​13120)
  • Ensure UpdatePodSandbox returns Unimplemented instead of a generic error (#​13023)
Go client
  • Handle absolute symlinks in rootfs user lookup to fix regressions when using Go 1.24 (#​13015)
Image Distribution
  • Enable mount manager in diff walking to fix layer extraction errors with some snapshotters (e.g., EROFS) (#​13198)
  • Apply hardening to prevent TOCTOU race during tar extraction (#​12971)
Runtime
  • Restore support for client-mounted roots in Windows containers using process isolation (#​13195)
  • Update runc to v1.3.5 (#​13061)
  • Apply absolute symlink resolution to /etc/group in OCI spec to fix lookups on NixOS-style systems (#​13019)
  • Handle absolute symlinks in rootfs user lookup to fix regressions when using Go 1.24 (#​13015)
Snapshotters
  • Fix bug that caused whiteouts to be ignored when parallel unpack was used (#​13125)

Please try out the release binaries and report any issues at
https://github.com/containerd/containerd/issues.

Contributors
  • Samuel Karp
  • Sebastiaan van Stijn
  • Maksym Pavlenko
  • Chris Henzie
  • Derek McGowan
  • Paulo Oliveira
  • Henry Wang
  • Phil Estes
  • Wei Fu
  • Akihiro Suda
  • Gao Xiang
  • Ricardo Branco
  • Shachar Tal
Changes
40 commits

  • Prepare release notes for v2.2.3 (#​13224)
  • update github.com/moby/spdystream v0.5.1 (#​13217)
    • 31bd34a06 update github.com/moby/spdystream v0.5.1
  • vendor: github.com/klauspost/compress v1.18.5 (#​13197)
    • 1336f6c45 vendor: github.com/klauspost/compress v1.18.5
  • diff/walking: enable mount manager (#​13198)
    • 409f75be8 diff/walking: enable mount manager
  • update runhcs to v0.14.1 (#​13195)
  • vendor: github.com/Microsoft/hcsshim v0.14.1 (#​13196)
    • 8bd1b74e5 vendor: github.com/Microsoft/hcsshim v0.14.1
    • c6b0be8e1 vendor: github.com/Microsoft/hcsshim v0.14.0
  • update to Go 1.25.9, 1.26.2 (#​13190)
  • Skip TestExportAndImportMultiLayer on s390x (#​13154)
    • be554f478 Skip TestExportAndImportMultiLayer on s390x
  • Tweak mount info for overlayfs in case of parallel unpack (#​13125)
    • 660de195b Tweak mount info for overlayfs in case of parallel unpack
    • bc9274a4b Add integration test for issue 13030
  • Preserve cgroup mount options for privileged containers (#​13120)
    • c387890b5 Add integration test for privileged container cgroup mounts
    • 047a335a6 Forward RUNC_FLAVOR env var down to integration tests
    • 9b2d72ee0 Preserve host cgroup mount options for privileged containers
    • 5b66cd6a0 Move cgroup namespace placement higher in spec builder
  • update runc binary to v1.3.5 (#​13061)
    • 584205c2f [release/2.2] update runc binary to v1.3.5
  • Fix vagrant on CI (#​13066)
  • Fix TOCTOU race bug in tar extraction (#​12971)
    • fbed68b8f Fix TOCTOU race bug in tar extraction
  • cri: UpdatePodSandbox should return Unimplemented (#​13023)
    • a83510103 cri: UpdatePodSandbox should return Unimplemented
  • fix(oci): apply absolute symlink resolution to /etc/group (#​13019)
    • ee4179e52 fix(oci): apply absolute symlink resolution to /etc/group
  • fix(oci): handle absolute symlinks in rootfs user lookup (#​13015)
    • fd061b848 test(oci): use fstest and mock fs for better symlink coverage
    • 5d44d2c22 fix(oci): handle absolute symlinks in rootfs user lookup
  • update to go1.25.8, test go1.26.1 (#​13011)
    • 00c776f07 update to go1.25.8, test go1.26.1

Dependency Changes
  • github.com/Microsoft/hcsshim v0.14.0-rc.1 -> v0.14.1
  • github.com/klauspost/compress v1.18.1 -> v1.18.5
  • github.com/moby/spdystream v0.5.0 -> v0.5.1

Previous release can be found at v2.2.2

Which file should I download?
  • containerd-<VERSION>-<OS>-<ARCH>.tar.gz: ✅Recommended. Dynamically linked with glibc 2.35 (Ubuntu 22.04).
  • containerd-static-<VERSION>-<OS>-<ARCH>.tar.gz: Statically linked. Expected to be used on Linux distributions that do not use glibc >= 2.35. Not position-independent.

In addition to containerd, typically you will have to install runc
and CNI plugins from their official sites too.

See also the Getting Started documentation.


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 this update again.


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

This PR has been generated by Renovate Bot.

Copy link
Copy Markdown

@nicholasdille-bot nicholasdille-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-approved because label type/renovate is present.

@github-actions
Copy link
Copy Markdown

🔍 Vulnerabilities of ghcr.io/uniget-org/tools/containerd:2.2.3

📦 Image Reference ghcr.io/uniget-org/tools/containerd:2.2.3
digestsha256:ddc859396c5a2358cc7bc567c73cf86b2752d28492688e6f689adece04fdd7d8
vulnerabilitiescritical: 1 high: 3 medium: 2 low: 0
platformlinux/amd64
size36 MB
packages172
critical: 1 high: 0 medium: 0 low: 0 google.golang.org/grpc 1.78.0 (golang)

pkg:golang/google.golang.org/grpc@1.78.0

critical 9.1: CVE--2026--33186 Improper Authorization

Affected range<1.79.3
Fixed version1.79.3
CVSS Score9.1
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Score0.016%
EPSS Percentile3rd 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:

  1. 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).
  2. 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.

critical: 0 high: 2 medium: 0 low: 0 go.opentelemetry.io/otel/sdk 1.38.0 (golang)

pkg:golang/go.opentelemetry.io/otel/sdk@1.38.0

high 7.3: CVE--2026--39883 Untrusted Search Path

Affected range>=1.15.0
<=1.42.0
Fixed version1.43.0
CVSS Score7.3
CVSS VectorCVSS: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 Score0.006%
EPSS Percentile0th 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

  1. Attacker has local access to a system running a Go application that imports go.opentelemetry.io/otel/sdk
  2. Attacker places a malicious kenv binary earlier in $PATH
  3. Application initializes OpenTelemetry resource detection at startup
  4. hostIDReaderBSD.read() calls exec.Command("kenv", ...) which resolves to the malicious binary
  5. 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.

high 7.0: CVE--2026--24051 Untrusted Search Path

Affected range>=1.21.0
<1.40.0
Fixed version1.40.0
CVSS Score7
CVSS VectorCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
EPSS Score0.008%
EPSS Percentile1st 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

critical: 0 high: 1 medium: 0 low: 0 github.com/go-jose/go-jose/v4 4.1.3 (golang)

pkg:golang/github.com/go-jose/go-jose@4.1.3#v4

high 7.5: CVE--2026--34986 Uncaught Exception

Affected range<4.1.4
Fixed version4.1.4
CVSS Score7.5
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.019%
EPSS Percentile5th 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.

critical: 0 high: 0 medium: 1 low: 0 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

medium 5.3: CVE--2026--39882 Memory Allocation with Excessive Size Value

Affected range<1.43.0
Fixed version1.43.0
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.016%
EPSS Percentile3rd 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):

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

critical: 0 high: 0 medium: 1 low: 0 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

medium 5.3: CVE--2026--39882 Memory Allocation with Excessive Size Value

Affected range<1.43.0
Fixed version1.43.0
CVSS Score5.3
CVSS VectorCVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS Score0.016%
EPSS Percentile3rd 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):

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

@github-actions
Copy link
Copy Markdown

@github-actions
Copy link
Copy Markdown

@github-actions github-actions Bot merged commit 4760ced into main Apr 15, 2026
9 of 10 checks passed
@github-actions github-actions Bot deleted the renovate/containerd-2.2.x branch April 15, 2026 03:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants