You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Windows, when the target of Root.Mkdir or Root.MkdirAll is a junction pointing to an empty location, the operation can create a directory at the junction target even when that target is located outside the root. This only applies to operations where the last path component is a junction (path/to/junction, but not path/junction/target).
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.574%
EPSS Percentile
46th percentile
Description
The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.394%
EPSS Percentile
32nd percentile
Description
Multiple ECH outer extension references are not permitted under RFC 9849; previously, a client could send a well-crafted packet that could trigger memory exhaustion in the server process by specifying multiple references.
We now reject these as malformed and curb the memory amplification vector as a result.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.404%
EPSS Percentile
33rd percentile
Description
Parsing a multipart form can bypass memory limits and read an arbitrarily long line into memory when the remaining limit at the start of a part is less than 400 bytes.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.315%
EPSS Percentile
23rd percentile
Description
When an HTTP server handler sends a 2xx response to an HTTP/1 CONNECT request and returns without hijacking the connection, the server improperly continues to read and serve requests from the connection. Since a 2xx response to an HTTP/1 CONNECT converts the connection into a tunnel, the server should not treat the connection as continuing to contain HTTP.
The impact of this misbehavior is mostly limited to potential request smuggling, where an intermediate proxy considers the data on the connection to be tunneled and the server considers it to be HTTP.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.568%
EPSS Percentile
45th percentile
Description
A malicious HTTP/2 peer can cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.379%
EPSS Percentile
30th percentile
Description
When parsing a Range header containing a large number of small ranges, FileServer(FS), ServeContent, and ServeFile(FS) can consume an excessive amount of CPU.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.303%
EPSS Percentile
21st percentile
Description
Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.570%
EPSS Percentile
46th percentile
Description
When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.309%
EPSS Percentile
22nd percentile
Description
When http.Transport sends an HTTP/1 CONNECT request with a non-empty Request.Body, it writes the body directly to the connection without framing after the request headers. If the server rejects the CONNECT request with a non-2xx keep-alive response, Transport returns the connection to the idle pool. Because CONNECT requests do not have a request body, the server may interpret the trailing body bytes as a subsequent pipelined HTTP/1.1 request on the connection, leaving the pooled connection desynchronized and causing the next caller that reuses it to read the response to the injected request. In reverse proxies (including httputil.ReverseProxy) that forward CONNECT requests through a shared Transport, this can lead to cross-user response poisoning.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.181%
EPSS Percentile
7th percentile
Description
HTTP/2 servers could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.181%
EPSS Percentile
7th percentile
Description
A trusted template author may have previously written a valid template wherein the use of the 'yield' keyword would not be correctly escaped.
We now ensure that valid keyword uses are escaped and non-keyword uses are not escaped.
Affected range
<1.26.9
Fixed version
1.26.9
EPSS Score
0.181%
EPSS Percentile
7th percentile
Description
When a JavaScript template literal contains consecutive expressions, the context tracking state was not properly reset upon entering a new expression.
We now ensure that template-literal expression entries correctly reset context variables so all subsequent regular expression literals are accurately recognized and escaped.
golang.org/x/net0.56.0 (golang)
pkg:golang/golang.org/x/net@0.56.0
Affected range
<0.60.0
Fixed version
0.60.0
EPSS Score
0.574%
EPSS Percentile
46th percentile
Description
The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control.
Affected range
<0.60.0
Fixed version
0.60.0
EPSS Score
0.568%
EPSS Percentile
45th percentile
Description
A malicious HTTP/2 peer can cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values.
Affected range
<0.60.0
Fixed version
0.60.0
EPSS Score
0.303%
EPSS Percentile
21st percentile
Description
Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling.
Affected range
<0.60.0
Fixed version
0.60.0
EPSS Score
0.570%
EPSS Percentile
46th percentile
Description
When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.
Affected range
<0.60.0
Fixed version
0.60.0
EPSS Score
0.181%
EPSS Percentile
7th percentile
Description
HTTP/2 servers could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.
A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low. This advisory outlines the issue, identifies the affected versions, and provides remediation steps for impacted users.
Impact
Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.
A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.
Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.
Vulnerability details
AuthZ bypass and privilege escalation: An attacker could exploit a bypass using an API request with Content-Length set to 0, causing the Docker daemon to forward the request without the body to the AuthZ plugin, which might approve the request incorrectly.
Initial fix: The issue was fixed in Docker Engine v18.09.1 January 2019..
Regression: The fix was not included in Docker Engine v19.03 or newer versions. This was identified in April 2024 and patches were released for the affected versions on July 23, 2024. The issue was assigned CVE-2024-41110.
Patches
docker-ce v27.1.1 containes patches to fix the vulnerability.
Patches have also been merged into the master, 19.0, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches.
Remediation steps
If you are running an affected version, update to the most recent patched version.
Mitigation if unable to update immediately:
Avoid using AuthZ plugins.
Restrict access to the Docker API to trusted parties, following the principle of least privilege.
A race condition during docker cp mount setup allows a malicious container to redirect a bind mount target to an arbitrary host path, potentially overwriting host files or causing denial of service.
Details
When copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination is created inside the container root and then a bind mount is attached using the container-relative path resolved to an absolute host path.
Between mountpoint creation and the mount() syscall, a process running inside the container can replace the destination (or a parent path component) with a symlink pointing to an arbitrary location on the host. The mount() syscall follows the symlink, causing the volume to be bind-mounted onto an arbitrary host path instead of the intended container path.
Impact
A malicious container can redirect a volume bind mount to an arbitrary host path. The impact depends on the volume content and mount options:
If the volume is writable, arbitrary host files at the redirected path could be overwritten with the volume's contents.
If the volume is read-only, the host path is masked by the mount for the duration of the operation, causing denial of service.
In all cases the mount is temporary (torn down after the docker cp completes), but the effects of any writes persist.
Conditions for exploitation
A container must have at least one volume mount.
A process inside the container must be able to rapidly create and swap symlinks at the volume mount destination path.
An operator must initiate a docker cp into that container, or call the PUT /containers/{id}/archive or HEAD /containers/{id}/archive API endpoints.
Not affected
Containers that do not have volume mounts are not affected, as the race occurs during volume bind-mount setup.
Workarounds
Only run containers from trusted images.
Avoid using docker cp with untrusted running containers.
Use authorization plugins to restrict access to the archive API endpoints (PUT /containers/{id}/archive, HEAD /containers/{id}/archive).
Uncontrolled Search Path Element
Affected range
<=28.5.2
Fixed version
Not Fixed
CVSS Score
7.2
CVSS Vector
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:N
EPSS Score
0.165%
EPSS Percentile
5th percentile
Description
Summary
When a user uploads a compressed archive into a container, a malicious image can execute arbitrary code with daemon (host root) privileges.
Details
When handling PUT /containers/{id}/archive requests with compressed archives, the daemon decompresses them using external system binaries. Due to incorrect ordering of operations, these binaries are resolved from the container's filesystem rather than the host's. A container image that includes a trojanized decompression binary can achieve code execution as the daemon process whenever a compressed archive is uploaded to that container.
The executed binary runs with the daemon's full privileges, including host root UID and unrestricted capabilities.
Impact
Arbitrary code execution as host root, crossing the container-to-host trust boundary.
Conditions for exploitation
A user must run a container from a malicious image that contains a trojanized decompression binary.
The user must then upload a compressed archive (xz or gzip) into that container, either by piping a compressed archive via docker cp - or by calling the PUT /containers/{id}/archive API directly with compressed content.
Not affected
Standard docker cp usage is not affected, because the CLI sends uncompressed tar by default:
docker cp ./file.txt mycontainer:/file.txt
This can only be exploited when explicitly passing a xz or gzip-compressed archive to docker cp or the PUT /containers/{id}/archive API, for example:
cat archive.tar.xz | docker cp - mycontainer:/dir
Decompression formats using pure Go implementations (bzip2, zstd, and gzip when the container image does not contain an unpigz binary) are also not affected.
Workarounds
Only run containers from trusted images.
Use authorization plugins to limit access to the PUT /containers/{id}/archive endpoint.
Avoid piping compressed archives into containers created from untrusted images.
Off-by-one Error
Affected range
<29.3.1
Fixed version
Not Fixed
CVSS Score
6.8
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
EPSS Score
0.512%
EPSS Percentile
42nd percentile
Description
Summary
A security vulnerability has been detected that allows plugins privilege validation to be bypassed during docker plugin install. Due to an error in the daemon's privilege comparison logic, the daemon may incorrectly accept a privilege set that differs from the one approved by the user.
Plugins that request exactly one privilege are also affected, because no comparison is performed at all.
Impact
If plugins are not in use, there is no impact.
When a plugin is installed, the daemon computes the privileges required by the plugin's configuration and compares them with the privileges approved during installation. A malicious plugin can exploit this bug so that the daemon accepts privileges that differ from what was intended to be approved.
Anyone who depends on the plugin installation approval flow as a meaningful security boundary is potentially impacted.
Depending on the privilege set involved, this may include highly sensitive plugin permissions such as broad device access.
For consideration: exploitation still requires a plugin to be installed from a malicious source, and Docker plugins are relatively uncommon. Docker Desktop also does not support plugins.
Workarounds
If unable to update immediately:
Do not install plugins from untrusted sources
Carefully review all privileges requested during docker plugin install
Restrict access to the Docker daemon to trusted parties, following the principle of least privilege
Avoid relying on plugin privilege approval as the only control boundary for sensitive environments
Credits
Reported by Cody (c@wormhole.guru, PGP 0x9FA5B73E)
Time-of-check Time-of-use (TOCTOU) Race Condition
Affected range
<=28.5.2
Fixed version
Not Fixed
CVSS Score
6.1
CVSS Vector
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:N/I:L/A:H
EPSS Score
0.098%
EPSS Percentile
1st percentile
Description
Summary
A race condition during docker cp mount setup allows a malicious container to create empty files or directories at arbitrary absolute paths on the host filesystem.
This advisory covers the race during mountpoint creation. The related race during the subsequent mount syscall is tracked in GHSA-rg2x-37c3-w2rh
Details
When copying files into a container, the daemon sets up a temporary filesystem view by bind-mounting volumes into a private mount namespace. During this setup, the mount destination path is first resolved within the container's root filesystem using GetResourcePath, and then used to create the mountpoint (file or directory) if it does not already exist via createIfNotExists.
Between path resolution and mountpoint creation, a process running inside the container can swap a path component for a symlink pointing to an arbitrary location on the host. Because createIfNotExists operates on the already-resolved absolute path using standard os.MkdirAll and os.OpenFile — which follow symlinks in intermediate path components — the symlink is followed and the file or directory is created outside the container root filesystem, as root.
Impact
A malicious container can create empty files or directories at arbitrary absolute paths on the host filesystem, running as root. This enables persistent denial of service — for example:
Converting /etc/docker/daemon.json into a directory prevents the daemon from restarting
Creating /etc/nologin prevents user logins
Overwriting critical system paths with empty files can break host services
The container does not gain read or write access to existing host files — only the ability to create new empty files or directories at chosen paths.
Conditions for exploitation
A container must be running with a process that can rapidly create and swap symlinks at a volume mount destination path.
An operator must initiate a docker cp into that container, or call the PUT /containers/{id}/archive or HEAD /containers/{id}/archive API endpoints.
Not affected
Containers that do not have volume mounts are not affected, as the race occurs during volume bind-mount setup.
Patches
Mountpoint creation is now scoped to the container root using os.Root (Go 1.24+), which refuses to follow symlinks that escape the opened root directory. All filesystem operations in createIfNotExists (MkdirAll, OpenFile) are performed through the os.Root handle, so even if a symlink swap occurs after path resolution, the creation stays confined to the container root.
Workarounds
Only run containers from trusted images.
Avoid using docker cp with untrusted running containers.
Use authorization plugins to restrict access to the archive API endpoints (PUT /containers/{id}/archive, HEAD /containers/{id}/archive).
Missing Initialization of Resource
Affected range
<=25.0.12
Fixed version
25.0.13
CVSS Score
3.3
CVSS Vector
CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N
EPSS Score
0.155%
EPSS Percentile
4th percentile
Description
Moby is an open source container framework developed by Docker Inc. that is distributed as Docker Engine, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (dockerd), which is developed as moby/moby is commonly referred to as Docker, or Docker Engine.
Firewalld is a daemon used by some Linux distributions to provide a dynamically managed firewall. When Firewalld is running, Docker uses its iptables backend to create rules, including rules to isolate containers in one bridge network from containers in other bridge networks.
Impact
The iptables rules created by Docker are removed when firewalld is reloaded using, for example "firewall-cmd --reload", "killall -HUP firewalld", or "systemctl reload firewalld".
When that happens, Docker must re-create the rules. However, in affected versions of Docker, the iptables rules that isolate containers in different bridge networks from each other are not re-created.
Once these rules have been removed, containers have access to any port, on any container, in any non-internal bridge network, running on the Docker host.
Containers running in networks created with --internal or equivalent have no access to other networks. Containers that are only connected to these networks remain isolated after a firewalld reload.
Where Docker Engine is not running in the host's network namespace, it is unaffected. Including, for example, Rootless Mode, and Docker Desktop.
Patches
Moby releases 28.0.0 and newer are not affected. A fix is available in moby release 25.0.13.
Previously, a channel registered in the mux's chanList is not usable until it is established. A malicious peer was able flood the channel's incomingRequests, deadlocking the entire connection.
Now, we add an atomic established state, set when a channel becomes usable. Until such a time, handlePacket drops every packet other than the open confirmation/failure, without blocking and without tearing down the connection.
Affected range
<0.56.0
Fixed version
0.56.0
EPSS Score
0.500%
EPSS Percentile
41st percentile
Description
Previously, after a channel has been established, a malicious peer could send crafted messages that would deadlock the entire connection.
Now, we handle all RFC 4254 channel messages; global requests are handled explicitly. Then, treat all other messages as a protocol error and tear the connection down instead of buffering and blocking.
Affected range
<0.55.0
Fixed version
0.55.0
EPSS Score
0.437%
EPSS Percentile
36th percentile
Description
The source-address critical option in the Permissions returned by an authentication callback was only enforced for the PublicKeyCallback and VerifiedPublicKeyCallback paths, extending the fix for CVE-2026-46595. Permissions returned by the PasswordCallback, KeyboardInteractiveCallback, NoClientAuthCallback, and GSSAPIWithMICConfig.AllowLogin callbacks were not validated against the client's remote address, so a source-address restriction set by those callbacks was silently ignored. The check is now applied to the Permissions returned by any authentication callback.
Affected range
>=0
Fixed version
Not Fixed
Description
The golang.org/x/crypto/openpgp package is unsafe by design, has numerous known security issues, is not maintained, and should not be used.
If you are required to interoperate with OpenPGP systems and need a maintained package, consider github.com/ProtonMail/go-crypto/openpgp which is a maintained fork that aims to be a drop-in replacement for this package.
A vulnerability exists in gRPC-Go servers configured with xds.NewGRPCServer() where a crafted request missing both :authority and Host headers can cause a server panic, resulting in a Denial of Service (DoS).
Servers built with xds.NewGRPCServer install an xDS routing interceptor on every RPC. This interceptor looks up the request’s :authority header to pick a virtual host. The HTTP/2 server transport previously accepted requests that had neither :authority nor Host. When this happened, the xDS routing interceptor attempted to access the first element of an empty slice of authorities, leading to an index out of bounds panic. Since the per-RPC goroutine does not recover from panics, the entire server process would terminate.
This panic occurs in the interceptor pipeline, meaning the transport credentials handshake (TLS, mTLS, or ALTS) and HTTP/2 connection establishment must complete successfully before the crafted request can reach this logic.
Insecure/Standard TLS: If the server permits insecure (plaintext) connections or standard credentials (where client certs are not checked), any unauthenticated remote attacker can trigger the crash.
mTLS / ALTS: If strict transport-level authentication is enforced at the network edge or transport layer (e.g., requiring a valid client certificate), the attacker must possess valid transport credentials to initiate the stream and trigger the panic.
Impact
An attacker can cause a complete outage of the gRPC server by sending a request missing both :authority and Host headers, provided they can successfully establish a transport connection.
Patches
The issue has been addressed in master (and backported to 1.84.0, 1.83.2 and 1.82.2). The fix updates the HTTP/2 transport layer to reject requests missing both :authority and Host headers early, maintaining consistency with and other gRPC language implementations.
An unauthenticated remote attacker can initiate a gRPC stream and purposefully fragment their payload into millions of tiny (e.g., 1-byte) HTTP/2 DATA frames. Even if the total payload volume falls within the configured connection and stream flow-control windows, each independent fragment incurs memory overhead due to internal tracking structures and queue allocation.
Repeated fragmentation massively inflates the heap space consumed by the stream. An attacker multiplexing multiple concurrent streams can exhaust the memory bounds of the runtime, forcing a runtime panic or OutOfMemory condition and leading to a remote Denial of Service (DoS).
Patches
The change to fix this issue is merged in master and a patch release, 1.83.1, has been published that contains this fix.
Workarounds
This vulnerability is mitigated by implementing receive buffer compaction. Consecutive small data buffers are automatically coalesced into larger buffers from a shared pool once the overhead is perceived to be excessive relative to actual payload data, drastically minimizing per-frame memory overheads.
This behavior is enabled by default. A temporary escape hatch is provided via the environment variable GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION=false to disable the feature if unforeseen issues arise, but it will be removed in a future release.
A vulnerability in the xDS RBAC HTTP filter implementation in grpc-go allows remote attackers to bypass authorization policies (specifically DENY rules) by using mixed-case or canonical-case header matchers (e.g., X-Role instead of x-role). Additionally, the safety guards introduced by gRFC A41 to block grpc- prefixed headers can be evaded via variations in casing (e.g., Grpc-Status).
Impact
When an operator defines an RBAC policy referencing headers containing uppercase letters (e.g. X-Role), grpc-go fails to match incoming metadata keys because they are unconditionally lowercased. Because of this case-sensitivity mismatch, a policy designed to block requests containing specific header values fails open: the rule is evaluated as a non-match, and traffic that should have been rejected is served.
Furthermore, gRFC A41 requires rejecting configuration schemas specifying header matchers starting with grpc-. Because this check is executed case-sensitively in grpc-go, attackers can bypass the validation by specifying titles like Grpc-Status.
Patches
The problem is fixed in master and in the 1.83.1 release.
An overly broad default permission vulnerability was found in containerd.
/var/lib/containerd was created with the permission bits 0o711, while it should be created with 0o700
Allowed local users on the host to potentially access the metadata store and the content store
/run/containerd/io.containerd.grpc.v1.cri was created with 0o755, while it should be created with 0o700
Allowed local users on the host to potentially access the contents of Kubernetes local volumes. The contents of volumes might include setuid binaries, which could allow a local user on the host to elevate privileges on the host.
/run/containerd/io.containerd.sandbox.controller.v1.shim was created with 0o711, while it should be created with 0o700
The directory paths may differ depending on the daemon configuration.
When the temp directory path is specified in the daemon configuration, that directory was also created with 0o711, while it should be created with 0o700.
Patches
This bug has been fixed in the following containerd versions:
2.2.0
2.1.5
2.0.7
1.7.29
Users should update to these versions to resolve the issue.
These updates automatically change the permissions of the existing directories.
[!NOTE]
/run/containerd and /run/containerd/io.containerd.runtime.v2.task are still created with 0o711.
This is an expected behavior for supporting userns-remapped containers.
Workarounds
The system administrator on the host can manually chmod the directories to not
have group or world accessible permisisons:
A vulnerability exists in containerd's image pull handlers where a crafted OCI image index containing deeply nested or heavily fanned-out descriptor graphs can cause unbounded CPU and memory consumption. During the PullImage operation, the recursive traversal and processing of child descriptors lack sufficient depth and breadth limits, and fail to adequately deduplicate identical descriptors. This unbounded traversal leads to excessive resource allocation.
Consequently, pulling a malicious image reference can result in prolonged stalls during container creation and significant resource pressure on the host system. This issue occurs entirely during the image pull phase, prior to any container execution.
Patches
This bug has been fixed in containerd 2.4.1, 2.3.6, 2.2.9, 2.0.13, and 1.7.36. Users should update to these versions to resolve the issue.
Workarounds
There are no known workarounds for this issue. Users are advised to only pull trusted images from known registries until the patch can be applied.
Credits
The containerd project would like to thank Jakub Ciolek at ElevenLabs and @jlgore who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy.
For more information
If you have any questions or comments about this advisory:
A bug in containerd's CRI ExecSync implementation allows exec probes and lifecycle hooks with background child processes to keep containerd's stdio-drain goroutines indefinitely blocked. Because the I/O drain phase lacks a default timeout or context cancellation handling, repeated ExecSync invocations (like probes) that include long-lived background processes against a container can cause containerd to leak goroutines and host memory. Over time, this resource exhaustion can cause the containerd daemon to be terminated by the OOM killer, rendering containerd unavailable until it is restarted. This issue affects containerd on Linux systems running with the CRI plugin enabled. Users not using containerd's CRI implementation or not running containers on Linux are not affected.
Patches
This bug has been fixed in containerd 2.3.5, 2.2.8, 2.0.12, and 1.7.35. Users should update to these versions to resolve the issue.
Workarounds
Ensure exec probes and lifecycle hooks do not launch long-lived background child processes.
Credits
The containerd project would like to thank XlabAI Team of Tencent Xuanwu Lab (xlabai@tencent.com), including Guannan Wang, Zhanpeng Liu, Jiashuo Liang, and Guancheng Li, and @IamwhatIamSY who independently discovered and responsibly disclosed this issue in accordance with the containerd security policy.
For more information
If there are any questions or comments about this advisory:
Send an email to [security@containerd.io](mailto:security@containerd.io)
Integer Overflow or Wraparound
Affected range
<1.6.38
Fixed version
1.6.38
CVSS Score
4.6
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N
EPSS Score
0.300%
EPSS Percentile
21st percentile
Description
Impact
A bug was found in containerd where containers launched with a User set as a UID:GID larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user.
Patches
This bug has been fixed in the following containerd versions:
Email us at [security@containerd.io](mailto:security@containerd.io)
Affected range
<=1.6.25
Fixed version
1.6.26
Description
/sys/devices/virtual/powercap accessible by default to containers
Intel's RAPL (Running Average Power Limit) feature, introduced by the Sandy Bridge microarchitecture, provides software insights into hardware energy consumption. To facilitate this, Intel introduced the powercap framework in Linux kernel 3.13, which reads values via relevant MSRs (model specific registers) and provides unprivileged userspace access via sysfs. As RAPL is an interface to access a hardware feature, it is only available when running on bare metal with the module compiled into the kernel.
By 2019, it was realized that in some cases unprivileged access to RAPL readings could be exploited as a power-based side-channel against security features including AES-NI (potentially inside a SGX enclave) and KASLR (kernel address space layout randomization). Also known as the PLATYPUS attack, Intel assigned CVE-2020-8694 and CVE-2020-8695, and AMD assigned CVE-2020-12912.
Several mitigations were applied; Intel reduced the sampling resolution via a microcode update, and the Linux kernel prevents access by non-root users since 5.10. However, this kernel-based mitigation does not apply to many container-based scenarios:
Unless using user namespaces, root inside a container has the same level of privilege as root outside the container, but with a slightly more narrow view of the system
sysfs is mounted inside containers read-only; however only read access is needed to carry out this attack on an unpatched CPU
While this is not a direct vulnerability in container runtimes, defense in depth and safe defaults are valuable and preferred, especially as this poses a risk to multi-tenant container environments. This is provided by masking /sys/devices/virtual/powercap in the default mount configuration, and adding an additional set of rules to deny it in the default AppArmor profile.
While sysfs is not the only way to read from the RAPL subsystem, other ways of accessing it require additional capabilities such as CAP_SYS_RAWIO which is not available to containers by default, or perf paranoia level less than 1, which is a non-default kernel tunable.
Docker CLI for Windows searches for plugin binaries in C:\ProgramData\Docker\cli-plugins, a directory that does not exist by default. A low-privileged attacker can create this directory and place malicious CLI plugin binaries (docker-compose.exe, docker-buildx.exe, etc.) that are executed when a victim user opens Docker Desktop or invokes Docker CLI plugin features, and allow privilege-escalation if the docker CLI is executed as a privileged user.
This issue affects Docker CLI through v29.1.5 (fixed in v29.2.0). It impacts Windows binaries acting as a CLI plugin manager via the [github.com/docker/cli/cli-plugins/manager](https://pkg.go.dev/github.com/docker/cli@v29.1.5+incompatible/cli-plugins/manager) package, which is consumed by downstream projects such as Docker Compose.
Docker Compose became affected starting in v2.31.0, when it incorporated the relevant CLI plugin manager code (see docker/compose#12300), and is fixed in v5.1.0.
This issue does not impact non-Windows binaries or projects that do not use the plugin manager code.
Patches
Fixed version starts with 29.2.0
This issue was fixed in docker/cli@1375933 (docker/cli#6713), which removed %PROGRAMDATA%\Docker\cli-plugins from the list of paths used for plugin-discovery on Windows.
Some cache backends allow configuring their credentials by setting secrets directly as attribute values in cache-to/cache-from configuration. If this was done by the user, these secure values could be captured together with OpenTelemetry trace as part of the arguments and flags for the traced CLI command. Passing tokens to Github cache backend via environment variables or using registry authentication is not affected.
If you passed a token value like this and use a custom OpenTelemetry collector for computing traces you should make sure that your traces are kept secure. OpenTelemetry traces are also saved in BuildKit daemon's history records.
Patches
Issue has been fixed in Buildx v0.21.3 or newer.
Workarounds
Avoid passing cache backend credentials with CLI arguments. Make sure access to traces and BuildKit history records is kept secure.
OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.
The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.
Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.
Details
When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:
the provider's span processors;
each processor's span exporter; and
for the OTLP trace exporter, its client configuration.
This causes the following values to be present in the event:
OTLP trace gRPC: the configured endpoint;
OTLP trace HTTP: the configured endpoint and the Insecure flag; and
Zipkin: the complete collector URL.
OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:
versions 1.5.0 through 1.14.x use V(1) for this Info event; and
versions 1.15.0 through 1.44.0 use V(4).
OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.
Proof of concept
The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:
For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.
Impact
This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.
There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.
Remediation
Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.
If an immediate upgrade is not possible:
keep OpenTelemetry internal logging below the Info verbosity described above;
do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and
restrict access to existing logs and rotate any credentials that may already have been recorded.
OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.
The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.
Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.
Details
When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:
the provider's span processors;
each processor's span exporter; and
for the OTLP trace exporter, its client configuration.
This causes the following values to be present in the event:
OTLP trace gRPC: the configured endpoint;
OTLP trace HTTP: the configured endpoint and the Insecure flag; and
Zipkin: the complete collector URL.
OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:
versions 1.5.0 through 1.14.x use V(1) for this Info event; and
versions 1.15.0 through 1.44.0 use V(4).
OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.
Proof of concept
The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:
For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.
Impact
This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.
There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.
Remediation
Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.
If an immediate upgrade is not possible:
keep OpenTelemetry internal logging below the Info verbosity described above;
do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and
restrict access to existing logs and rotate any credentials that may already have been recorded.
OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.
The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.
Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.
Details
When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:
the provider's span processors;
each processor's span exporter; and
for the OTLP trace exporter, its client configuration.
This causes the following values to be present in the event:
OTLP trace gRPC: the configured endpoint;
OTLP trace HTTP: the configured endpoint and the Insecure flag; and
Zipkin: the complete collector URL.
OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:
versions 1.5.0 through 1.14.x use V(1) for this Info event; and
versions 1.15.0 through 1.44.0 use V(4).
OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.
Proof of concept
The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:
For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.
Impact
This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.
There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.
Remediation
Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.
If an immediate upgrade is not possible:
keep OpenTelemetry internal logging below the Info verbosity described above;
do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and
restrict access to existing logs and rotate any credentials that may already have been recorded.
OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.
The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.
Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.
Details
When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:
the provider's span processors;
each processor's span exporter; and
for the OTLP trace exporter, its client configuration.
This causes the following values to be present in the event:
OTLP trace gRPC: the configured endpoint;
OTLP trace HTTP: the configured endpoint and the Insecure flag; and
Zipkin: the complete collector URL.
OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:
versions 1.5.0 through 1.14.x use V(1) for this Info event; and
versions 1.15.0 through 1.44.0 use V(4).
OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.
Proof of concept
The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:
For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.
Impact
This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.
There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.
Remediation
Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.
If an immediate upgrade is not possible:
keep OpenTelemetry internal logging below the Info verbosity described above;
do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and
restrict access to existing logs and rotate any credentials that may already have been recorded.
go.opentelemetry.io/otel/sdk1.44.0 (golang)
pkg:golang/go.opentelemetry.io/otel/sdk@1.44.0
Exposure of Sensitive Information to an Unauthorized Actor
OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.
The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.
Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.
Details
When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:
the provider's span processors;
each processor's span exporter; and
for the OTLP trace exporter, its client configuration.
This causes the following values to be present in the event:
OTLP trace gRPC: the configured endpoint;
OTLP trace HTTP: the configured endpoint and the Insecure flag; and
Zipkin: the complete collector URL.
OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:
versions 1.5.0 through 1.14.x use V(1) for this Info event; and
versions 1.15.0 through 1.44.0 use V(4).
OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.
Proof of concept
The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:
For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.
Impact
This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.
There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.
Remediation
Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.
If an immediate upgrade is not possible:
keep OpenTelemetry internal logging below the Info verbosity described above;
do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and
restrict access to existing logs and rotate any credentials that may already have been recorded.
OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.
The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.
Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.
Details
When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:
the provider's span processors;
each processor's span exporter; and
for the OTLP trace exporter, its client configuration.
This causes the following values to be present in the event:
OTLP trace gRPC: the configured endpoint;
OTLP trace HTTP: the configured endpoint and the Insecure flag; and
Zipkin: the complete collector URL.
OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:
versions 1.5.0 through 1.14.x use V(1) for this Info event; and
versions 1.15.0 through 1.44.0 use V(4).
OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.
Proof of concept
The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:
For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.
Impact
This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.
There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.
Remediation
Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.
If an immediate upgrade is not possible:
keep OpenTelemetry internal logging below the Info verbosity described above;
do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and
restrict access to existing logs and rotate any credentials that may already have been recorded.
OpenTelemetry Go versions 1.5.0 through 1.44.0 can include trace exporter endpoint configuration in an internal diagnostic log emitted when an SDK TracerProvider is created. The default OpenTelemetry logger does not emit this event. Exposure requires an application to install a logger that enables OpenTelemetry's internal Info-level diagnostics and for someone other than the intended audience to have access to those logs.
The logged configuration can disclose the address of the trace collector and whether the OTLP/HTTP connection is configured as insecure. The Zipkin exporter logs its complete collector URL, so credentials in URL userinfo or tokens in the query string are also disclosed if an application embeds them there. OTLP authentication headers, TLS key material, and exported span data are not included in this log.
Exporter MarshalLog implementations that caused this configuration to be included in internal logs were introduced by a1fff3c.
Details
When sdk/trace.NewTracerProvider constructs a provider, it records a TracerProvider created internal Info event containing the provider configuration. In affected versions, the configuration's MarshalLog methods recursively include:
the provider's span processors;
each processor's span exporter; and
for the OTLP trace exporter, its client configuration.
This causes the following values to be present in the event:
OTLP trace gRPC: the configured endpoint;
OTLP trace HTTP: the configured endpoint and the Insecure flag; and
Zipkin: the complete collector URL.
OpenTelemetry Go does not emit this event with its default logger, which only emits errors. An application must explicitly configure a sufficiently verbose logger with otel.SetLogger. The required logr verbosity is version-dependent:
versions 1.5.0 through 1.14.x use V(1) for this Info event; and
versions 1.15.0 through 1.44.0 use V(4).
OTLP header configuration is not part of the marshaled object, so credentials supplied with WithHeaders or the corresponding environment variables are not exposed. The documented OTLP WithEndpoint input is a collector address rather than a credential-bearing URL. The higher-risk case is therefore the Zipkin collector URL, which is retained and logged in full, or an application passing sensitive data in an OTLP endpoint outside the documented format.
Proof of concept
The following program demonstrates the behavior with OpenTelemetry Go 1.44.0. It deliberately places credentials and a token in the Zipkin collector URL and enables internal Info logging:
For versions before 1.15.0, set funcr.Options{Verbosity: 1} instead.
Impact
This is a conditional disclosure through application logs. Affected applications must enable verbose OpenTelemetry internal diagnostics and configure a trace exporter containing information they do not intend to expose to readers of those logs. In that configuration, a person or system with log access can learn the trace collector address and internal network topology. If credentials or tokens are embedded directly in a Zipkin collector URL, those values can also be recovered from the logs.
There is no exposure with the default OpenTelemetry logger, and the vulnerable log is generated from local application configuration rather than remotely supplied span data. OTLP authentication headers, certificate or private-key contents, and telemetry payloads are not logged by this path.
Remediation
Upgrade the affected OpenTelemetry Go modules to version 1.45.0 or later. The fix in 3a1412d stops recursively marshaling exporter and client configuration and records their types instead.
If an immediate upgrade is not possible:
keep OpenTelemetry internal logging below the Info verbosity described above;
do not embed credentials or tokens in exporter endpoint URLs; use authentication headers or another supported credential mechanism; and
restrict access to existing logs and rotate any credentials that may already have been recorded.
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
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.
nicholasdille-bot
left a comment
This PR contains the following updates:
2.102.19→2.102.21Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
depot/cli (depot)
v2.102.21: Depot CLI 2.102.21Compare Source
What's Changed
v2.102.20: Depot CLI 2.102.20Compare Source
What's Changed
Configuration
📅 Schedule: (in timezone Europe/Berlin)
🚦 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.
This PR has been generated by Mend Renovate CLI.