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
Deduplicate concurrent image volume MountImage calls to avoid containers/storage lock serialization when many pods mount the same image volume simultaneously. (#10255, @openshift-cherrypick-robot)
Fix a bug in high performance hooks where an init container would continue to hold a cpuset that could be used by a regular container in the same pod. (#10236, @openshift-cherrypick-robot)
Added support for per-container targeting of cpu-load-balancing.crio.io, irq-load-balancing.crio.io, and cpu-quota.crio.io annotations. A container name can be appended to the annotation key (e.g. cpu-load-balancing.crio.io/my-container: "disable") to apply the setting to a specific container rather than all containers in the pod. Container-specific annotations take precedence over pod-level annotations when both are present. (#10152, @openshift-cherrypick-robot)
Bug or Regression
Fix CRI-O crash (nil pointer dereference) in ListPodSandboxStats when a container's cgroup is cleaned up during teardown. (#10216, @openshift-cherrypick-robot)
Dependencies
Added
Nothing has changed.
Changed
Nothing has changed.
Removed
Nothing has changed.
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
Incorrect Implementation of Authentication Algorithm
Affected range
<0.52.0
Fixed version
0.52.0
CVSS Score
10
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L
EPSS Score
0.503%
EPSS Percentile
41st percentile
Description
Previously, CVE-2024-45337 fixed an authorization bypass for misused ssh server configurations; if any other type of callback is passed other than public key, then the source-address validation would be skipped.
Improper Certificate Validation
Affected range
<0.52.0
Fixed version
0.52.0
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
7.314%
EPSS Percentile
94th percentile
Description
Previously, a revoked 'SignatureKey' belonging to a CA was not correctly checked for revocation. Now, both the 'key' and 'key.SignatureKey' are checked for @Revoked.
Integer Overflow or Wraparound
Affected range
<0.52.0
Fixed version
0.52.0
CVSS Score
9.1
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
EPSS Score
0.525%
EPSS Percentile
43rd percentile
Description
When writing data larger than 4GB in a single Write call on an SSH channel, an integer overflow in the internal payload size calculation caused the write loop to spin indefinitely, sending empty packets without making progress. The size comparison now uses int64 to prevent truncation.
Missing Authorization
Affected range
<0.52.0
Fixed version
0.52.0
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.412%
EPSS Percentile
34th percentile
Description
The in-memory keyring returned by NewKeyring() silently accepted keys with the ConfirmBeforeUse constraint but never enforced it. The key would sign without any confirmation prompt, with no indication to the caller that the constraint was not in effect. NewKeyring() now returns an error when unsupported constraints are requested.
Improper Preservation of Permissions
Affected range
<0.52.0
Fixed version
0.52.0
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.600%
EPSS Percentile
46th percentile
Description
When adding a key to a remote agent constraint extensions such as restrict-destination-v00@openssh.com were not serialized in the request. Destination restrictions were silently stripped when forwarding keys, allowing unrestricted use of the key on the remote host. The client now serializes all constraint extensions. Additionally, the in-memory keyring returned by NewKeyring() now rejects keys with unsupported constraint extensions instead of silently ignoring them.
Missing Authorization
Affected range
<0.52.0
Fixed version
0.52.0
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.420%
EPSS Percentile
35th percentile
Description
The Verify() method for FIDO/U2F security key types (sk-ecdsa-sha2-nistp256@openssh.com, sk-ssh-ed25519@openssh.com) did not check the User Presence flag. Signatures generated without physical touch were accepted, allowing unattended use of a hardware security key. To restore the previous behavior, return a "no-touch-required" extension in Permissions.Extensions from PublicKeyCallback.
Improper Restriction of Operations within the Bounds of a Memory Buffer
Affected range
<0.52.0
Fixed version
0.52.0
CVSS Score
9.1
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
EPSS Score
0.621%
EPSS Percentile
47th percentile
Description
A malicious SSH peer could send unsolicited global request responses to fill an internal buffer, blocking the connection's read loop. The blocked goroutine could not be released by calling Close(), resulting in a resource leak per connection. Unsolicited global responses are now discarded.
Affected range
<0.56.0
Fixed version
0.56.0
Description
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
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.325%
EPSS Percentile
25th 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.
Incorrect Type Conversion or Cast
Affected range
<0.52.0
Fixed version
0.52.0
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.473%
EPSS Percentile
39th percentile
Description
An incorrectly placed cast from bytes to int allowed for server-side panic in the AES-GCM packet decoder for well-crafted inputs.
Improper Validation of Specified Quantity in Input
Affected range
<0.52.0
Fixed version
0.52.0
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.467%
EPSS Percentile
39th percentile
Description
The RSA and DSA public key parsers did not enforce size limits on key parameters. A crafted public key with an excessively large modulus or DSA parameter could cause several minutes of CPU consumption during signature verification. This could be triggered by unauthenticated clients during public key authentication. RSA moduli are now limited to 8192 bits, and DSA parameters are validated per FIPS 186-2.
Improper Enforcement of Message Integrity During Transmission in a Communication Channel
Affected range
<0.52.0
Fixed version
0.52.0
CVSS Score
6.5
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
EPSS Score
0.279%
EPSS Percentile
20th percentile
Description
An authenticated SSH client that repeatedly opened channels which were rejected by the server caused unbounded memory growth, eventually crashing the server process and affecting all connected users. Rejected channels are now properly removed from the connection's internal state and released for garbage collection.
Improper Preservation of Permissions
Affected range
<0.52.0
Fixed version
0.52.0
CVSS Score
6.3
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
EPSS Score
0.369%
EPSS Percentile
30th percentile
Description
When an SSH server authentication callback returned PartialSuccessError with non-nil Permissions, those permissions were silently discarded, potentially dropping certificate restrictions such as force-command after a second factor succeeded. Returning non-nil Permissions with PartialSuccessError now results in a connection error.
Improper Validation of Array Index
Affected range
<0.52.0
Fixed version
0.52.0
CVSS Score
5.3
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score
0.412%
EPSS Percentile
34th percentile
Description
For certain crafted inputs, a 'ed25519.PrivateKey' was created by casting malformed wire bytes, leading to a panic when used.
Improper Certificate Validation
Affected range
<0.52.0
Fixed version
0.52.0
CVSS Score
5.3
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
EPSS Score
0.504%
EPSS Percentile
41st percentile
Description
SSH servers which use CertChecker as a public key callback without setting IsUserAuthority or IsHostAuthority could be caused to panic by a client presenting a certificate. CertChecker now returns an error instead of panicking when these callbacks are nil.
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.
stdlib1.26.3 (golang)
pkg:golang/stdlib@1.26.3
Affected range
>=1.26.0-0 <1.26.6
Fixed version
1.26.6
EPSS Score
0.692%
EPSS Percentile
50th percentile
Description
The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error.
This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".
Affected range
>=1.26.0-0 <1.26.6
Fixed version
1.26.6
EPSS Score
0.568%
EPSS Percentile
45th percentile
Description
Handshake messages, such as KeyUpdate, are always considered as state-advancing, regardless of whether a handshake has been completed or not. As a result, a malicious client can keep sending KeyUpdate messages to force the server to keep performing key derivation operations indefinitely.
Affected range
>=1.26.0-0 <1.26.6
Fixed version
1.26.6
EPSS Score
0.568%
EPSS Percentile
45th percentile
Description
Previously, DecodeElement would reset the depth counter causing it to never fire; this could lead to stack exhaustion.
Affected range
>=1.26.0-0 <1.26.6
Fixed version
1.26.6
EPSS Score
0.568%
EPSS Percentile
45th percentile
Description
When a server is configured to support unencrypted HTTP/2, it reads a few bytes from each new connection to see if they contain the HTTP/2 client preface. ReadHeaderTimeout is unexpectedly not being applied when doing this.
Affected range
>=1.26.0-0 <1.26.6
Fixed version
1.26.6
EPSS Score
0.549%
EPSS Percentile
44th percentile
Description
Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.
Affected range
>=1.26.0-0 <1.26.4
Fixed version
1.26.4
EPSS Score
0.560%
EPSS Percentile
44th percentile
Description
Decoding a maliciously-crafted MIME header containing many invalid encoded-words can consume excessive CPU.
Affected range
>=1.26.0-0 <1.26.6
Fixed version
1.26.6
EPSS Score
0.568%
EPSS Percentile
45th percentile
Description
Enforce a recursion limit in Unmarshal to prevent stack exhaustion when parsing deeply-nested, recursive structures.
Affected range
>=1.26.0-0 <1.26.4
Fixed version
1.26.4
EPSS Score
0.591%
EPSS Percentile
46th percentile
Description
(*x509.Certificate).VerifyHostname previously called matchHostnames in a loop over all DNS Subject Alternative Name (SAN) entries. This caused strings.Split(host, ".") to execute repeatedly on the same input hostname.
With a large DNS SAN list, verification costs scaled quadratically based on the number of SAN entries multiplied by the hostname's label count. Because x509.Verify validates hostnames before building the certificate chain, this overhead occurred even for untrusted certificates.
Affected range
>=1.26.0-0 <1.26.6
Fixed version
1.26.6
EPSS Score
0.310%
EPSS Percentile
23rd percentile
Description
Previously, pathological inputs could close an unescaped '/' early, allowing for attack-controlled data to inject arbitrary content, potentially leading to XSS.
Affected range
>=1.26.0-0 <1.26.6
Fixed version
1.26.6
EPSS Score
0.518%
EPSS Percentile
42nd percentile
Description
Previously, resolving relative paths containing parent directory ('..') segments performed string conversions and buffer rewrites on each step, resulting in quadratic time complexity and high memory allocation overhead.
Now, path resolution operates on a byte buffer using index-based backtracking for '..' segments, eliminating the quadratic time complexity and significantly reducing memory allocations.
Affected range
>=1.26.0-0 <1.26.4
Fixed version
1.26.4
EPSS Score
0.370%
EPSS Percentile
30th percentile
Description
When returning errors, functions in the net/textproto package would include its input as part of the error. This might allow an attacker to inject misleading content to errors that are printed or logged.
Affected range
>=1.26.0-0 <1.26.5
Fixed version
1.26.5
EPSS Score
0.382%
EPSS Percentile
31st percentile
Description
Handshakes which used Encrypted Client Hello could be de-anonymized by a passive network observer due to a disclosure of pre-shared key identities in the unencrypted client hello.
Affected range
>=1.26.0-0 <1.26.5
Fixed version
1.26.5
EPSS Score
0.232%
EPSS Percentile
14th percentile
Description
On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root when the final path component of the a path is a symbolic link and the path ends in /.
For example, 'root.Open("symlink/")' will open "symlink" even when "symlink" is a symbolic link pointing outside of the root.
golang.org/x/net0.51.0 (golang)
pkg:golang/golang.org/x/net@0.51.0
Affected range
<0.55.0
Fixed version
0.55.0
EPSS Score
0.692%
EPSS Percentile
50th percentile
Description
The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error.
This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".
Affected range
<0.56.0
Fixed version
0.56.0
EPSS Score
0.549%
EPSS Percentile
44th percentile
Description
Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.
Affected range
<0.53.0
Fixed version
0.53.0
EPSS Score
0.781%
EPSS Percentile
54th percentile
Description
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.
Uncontrolled Resource Consumption
Affected range
<0.55.0
Fixed version
0.55.0
CVSS Score
6.5
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
EPSS Score
0.326%
EPSS Percentile
25th percentile
Description
In Go Net (golang.org/x/net) before verion 0.55.0, parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.
Affected range
<0.55.0
Fixed version
0.55.0
EPSS Score
0.235%
EPSS Percentile
14th percentile
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
Affected range
<0.55.0
Fixed version
0.55.0
EPSS Score
0.223%
EPSS Percentile
13th percentile
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
Affected range
<0.55.0
Fixed version
0.55.0
EPSS Score
0.223%
EPSS Percentile
13th percentile
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
Affected range
<0.55.0
Fixed version
0.55.0
EPSS Score
0.223%
EPSS Percentile
13th percentile
Description
Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.
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.161%
EPSS Percentile
6th 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.387%
EPSS Percentile
32nd 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.108%
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).
A bug was found in containerd where the CRI plugin propagates labels from an image config (LABEL instruction in Dockerfile) to a container without validation. This may result in executing an arbitrary command on the host, via a plugin that consumes container labels for some operations.
Patches
This bug has been fixed in the following containerd versions:
2.3.2
2.2.5
2.1.9
2.0.10
1.7.33
Users should update to these versions to resolve the issue.
Workarounds
Ensure that only trusted images are used.
Credits
The containerd project would like to thank Anthropic Research, in collaboration with Claude, the GKE Security Team using Gemini, and Robert Prast (@robertprast) for independently discovering and responsibly disclosing this issue in accordance with the containerd security policy.
For more information
If you have any questions or comments about this advisory:
A bug was found in containerd where containers launched with a numeric User directive that cannot be parsed as a 32-bit integer are incorrectly treated as a username. If a crafted image provides an /etc/passwd file mapping this large numeric string to root, the container ultimately runs as root (UID 0). This allows the Kubernetes runAsNonRoot restriction to be bypassed, causing 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:
2.3.1
2.2.4
2.0.9
1.7.32
Note: The containerd 2.1 release has reached its end of life and a fixed version is not provided.
Users should update to these versions to resolve the issue.
Workarounds
Ensure that only trusted images are used and that only trusted users have permissions to import images. Alternatively, enforcing a specific numeric runAsUser in the Kubernetes Pod securityContext overrides the USER directive in the image and prevents the bypass. Newer versions of Kubernetes, starting with 1.34, also appear to enforce runAsNonRoot properly regardless of this bug.
Credits
The containerd project would like to thank Lei Wang (@ssst0n3) for responsibly disclosing this issue in accordance with the containerd security policy.
A vulnerability in containerd allows a maliciously crafted image to cause a Denial of Service (DoS) condition. When creating a container from this image, memory exhaustion occurs, leading to an Out Of Memory (OOM) kill of the containerd process. This renders the container runtime API unavailable and can disrupt clients such as the Docker Engine or Kubernetes control-plane components.
Patches
This bug has been fixed in the following containerd versions:
2.3.2
2.2.5
2.1.9
2.0.10
1.7.33
Users should update to these versions to resolve the issue.
Workarounds
Ensure that only trusted images are used and that only trusted users have permissions to import images or schedule pods.
Credits
The containerd project would like to thank Jakub Ciolek (@jake-ciolek) at AlphaSense and Kyle Elliott @ Trail of Bits 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:
Email us at [security@containerd.io](mailto:security@containerd.io)
golang.org/x/mod0.32.0 (golang)
pkg:golang/golang.org/x/mod@0.32.0
Affected range
<0.40.0
Fixed version
0.40.0
EPSS Score
0.107%
EPSS Percentile
1st percentile
Description
A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allow for a requested module to bypass the GOSUMDB check and persist attacker-controlled module content to a local Go module cache.
This attack allows for a malicious GOPROXY to serve malicious module content that cannot be detected by evaluating the transparency log.
All tiles are now correctly verified against their parents.
In order to determine if you have been affected:
rm -r go.sum go.work.sum vendor/ && go mod tidy
Affected range
<0.40.0
Fixed version
0.40.0
EPSS Score
0.298%
EPSS Percentile
22nd percentile
Description
A malicious GOSUMDB was capable of serving arbitrary module content not contained within the transparency log.
This attack allows for a coordinating GOPROXY and GOSUMDB to serve a client malicious module content that cannot be detected by evaluating the transparency log.
Multiple security vulnerabilities have been identified and addressed in grpc-go affecting the xDS RBAC authorization engine (internal/xds/rbac) and the HTTP/2 transport server implementation (internal/transport). These vulnerabilities could result in:
Authorization Bypass (Fail-Open) when translating xDS RBAC policies containing Metadata or RequestedServerName fields.
Denial of Service (High CPU Consumption) due to an HTTP/2 Rapid Reset mitigation bypass during client-initiated stream resets.
Denial of Service (Server Panic) when parsing crafted xDS RBAC policies containing NOT rules around unsupported fields.
Impact
What kind of vulnerability is it? Who is impacted?
xDS RBAC Authorization Bypass via Metadata & RequestedServerName matchers
Affected Component: xDS RBAC
Impact: When building policy matchers for gRPC RBAC from xDS configurations, unsupported permission and principal rules (specifically Metadata and RequestedServerName) were silently ignored and treated as no-ops.
If an authorization policy relied purely on these matchers for access control, treating those rules as no-ops effectively removed the restrictions.
If these unsupported rules were nested inside logical NOT rules (Permission_NotRule / Principal_NotId) or multi-condition OR/AND rules, silently dropping them changed the boolean logic flow of the authorization engine.
As a result, policy evaluation decisions could fail open, allowing unauthorized clients to access protected gRPC services or resources.
HTTP/2 Rapid Reset Mitigation Bypass / Denial of Service via Stream Aborts
Affected Component: HTTP/2 transport
Impact: Earlier mitigations in grpc-go for HTTP/2 Rapid Reset only applied threshold checks to items that directly resulted in control frames being written back to the wire, such as SETTINGS ACKs or server-initiated RST_STREAMs.
When a client initiated a rapid flood of stream creation (HEADERS) immediately followed by stream termination RST_STREAM, items queued up in the control buffer without counting against the transport response frame threshold. An attacker can repeatedly trigger this flood sequence to bypass reader blocking, resulting in high CPU usage, and Denial of Service (DoS).
Denial of Service (Panic) in xDS RBAC Engine via Unsupported Fields inside NOT Rules
Affected Component: xDS RBAC
Impact: The xDS RBAC policy translators recursively generate matchers for nested rules. When a NOT rule wrapped an unsupported or unhandled field (such as SourcedMetadata), the recursive step returned an empty matcher. This could result in a runtime panic when the RBAC engine attempts to authorize an incoming request.
An attacker or misconfigured/malicious xDS management server delivering an LDS/RDS update containing a NOT rule around an unhandled field causes the gRPC server process to crash immediately (CWE-248 / Denial of Service).
Patches
Has the problem been patched? What versions should users upgrade to?
All three issues have been fixed in master and will be released in 1.82.1 shortly.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
If upgrading grpc-go immediately is not possible, apply the following workarounds based on your deployment architecture:
For xDS RBAC Vulnerabilities & Panics: Ensure that upstream xDS management servers do not push RBAC policies containing Metadata, RequestedServerName, or NOT rules wrapping unsupported fields (such as SourcedMetadata) to grpc-go servers.
For HTTP/2 Rapid Reset DOS: Configure upstream reverse proxies or load balancers (such as Envoy) with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.
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.
github.com/sigstore/fulcio1.8.3 (golang)
pkg:golang/github.com/sigstore/fulcio@1.8.3
Server-Side Request Forgery (SSRF)
Affected range
<=1.8.5
Fixed version
1.8.6
CVSS Score
8.7
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N
EPSS Score
0.175%
EPSS Percentile
7th percentile
Description
Impact
Three security vulnerabilities were identified in the OIDC Discovery client:
Blind Server-Side Request Forgery (SSRF) via Cross-Host Redirects:
Fulcio uses an HTTP client to fetch OIDC discovery metadata (/.well-known/openid-configuration). Prior to this fix, if a configured issuer returned an HTTP redirect to a different host, the client followed it by default. This allowed a compromised or malicious issuer to redirect Fulcio's discovery requests to internal-only systems, resulting in blind SSRF.
JWKS Substitution and Cache Poisoning:
Because cross-host redirects were permitted during OIDC discovery, an attacker could manipulate the discovery flow to return a malicious jwks_uri pointing to an attacker-controlled host. When Fulcio successfully initialized the provider and cached the resulting verifier in the verifier cache, it poisoned the cache with the attacker's verification keys. The attacker could then present signatures validated against the poisoned keys.
Kubernetes ServiceAccount Token Leakage:
Fulcio mounts an in-cluster Kubernetes ServiceAccount token to authenticate OIDC discovery requests sent to the local control plane API server (https://kubernetes.default.svc).
Cross-Host Redirects & JWKS: The token was previously attached globally by the transport, leaking it to third-party hosts if the issuer performed a redirect or if the jwks_uri pointed to a different domain.
Wildcard MetaIssuers: If a wildcard MetaIssuer of type kubernetes (e.g., matching external EKS/GKE endpoints) was matched, and a local Kubernetes issuer was present in the config, the transport loaded and attached the local in-cluster ServiceAccount token to outbound requests sent to the external host.
Patches
The following mitigations have been applied:
Blocked Cross-Host Redirects: A custom callback is configured on all OIDC discovery HTTP clients to reject redirects that attempt to cross the original issuer's host boundary.
Restricted Token Injection: Updated the transport to only attach the ServiceAccount token when the outgoing request's host exactly matches the configured host of the issuer.
Restricted Local Token Loading: Constrained the loader to only load and wrap the transport with the local ServiceAccount token when the target issuer URL exactly matches the private local API server (https://kubernetes.default.svc).
Workarounds
None, upgrade to v1.8.6
Server-Side Request Forgery (SSRF)
Affected range
<=1.8.4
Fixed version
1.8.5
CVSS Score
5.8
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
EPSS Score
0.224%
EPSS Percentile
13th percentile
Description
Security Disclosure: SSRF via MetaIssuer Regex Bypass
Summary
Fulcio's metaRegex() function uses unanchored regex, allowing attackers to bypass MetaIssuer URL validation and trigger SSRF to arbitrary internal services.
Since the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through Blind SSRF.
Impact
SSRF to cloud metadata (169.254.169.254)
SSRF to internal Kubernetes APIs
SSRF to any service accessible from Fulcio's network
Affects ALL deployments using MetaIssuers
Patches
Upgrade to v1.8.5.
Workarounds
None. If anchors are included in the meta issuer configuration URL, they will be escaped before the regular expression is compiled, not making this a sufficient mitigation. Deployments must upgrade to the latest Fulcio release v1.8.5.
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.
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
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.
When setting up the container rootfs, setupPtmx and setupDevSymlinks call os.Remove and os.Symlink with a filepath.Join string which allow an image with /dev as a symlink to trick runc into deleting files called ptmx on the host or creating a hardcoded set of symlinks with specific names and targets in an arbitrary pre-existing host directory.
Please note that this issue is not exploitable under Docker because it creates a top-level ro layer that masks any malicious /dev symlink present in the container image (this is also done without mounting the lower layers so there is no opportunity for the malicious /dev symlink to trick it into resolving to some other path). Unfortunately, Podman and containerd† do not do this and so users using those higher-level runtimes with runc can be exploited via a malicious image.
There are a few mitigating factors about this issue which reduce the impact for most users quite significantly, and is the reason why we decided to release the fix publicly without an embargo.
While the deletion of ptmx seems like a significant issue, in practice it is quite limited. Notably, devpts does not permit you to unlink /dev/pts/ptmx regardless of privileges and so it is not a usable target for this attack. Additionally, while /dev/ptmxcan be unlinked‡, trying to use an image with a symlink from /dev to /dev will cause runc will return an error before it reaches the buggy code (it correctly detects a symlink loop while setting up the mount target and the code correctly scopes the lookup inside the container). Thus, the only files called ptmx that are guaranteed to exist on the system cannot actually be removed by this bug and so only some user file that happens to have that specific name could be deleted, which seems fairly unlikely to happen on real systems.
As for the issue of symlinks, again the impact is likely quite limited. While the creation of arbitrary symlinks could be used to create drop-in files for system services (and thus lead to a container breakout), the hardcoded set of symlink names and targets that this bug allows you to create on the host make it quite unlikely that you would be able to do much more than pollute the host system with dummy symlinks. Here is the complete list of symlinks that can be created with this attack:
core → /proc/kcore
fd → /proc/self/fd/
ptmx → pts/ptmx
stdin → /proc/self/fd/0
stdout → /proc/self/fd/1
stderr → /proc/self/fd/2
Note that none of these symlinks are likely to point to user-controlled data -- the /proc/self/fd/$n symlinks are all properties of the process accessing them (so privileged processes will only see the state they were spawned with) and the pts/ptmx symlink is almost certainly in the same privilege scope as the directory the symlink itself is in. It seems the only somewhat plausible impact would be that a service could return an error when trying to parse one of these symlinks and thus treat it as an invalid configuration file. How arbitrary processes deal with this situation is a bit hard to analyse, but most daemons require configuration files to have certain suffixes (such as .conf) so it's not really clear how large the impact is in practice and it seems there are a few barriers to clear to use this to cause a DoS or other problems.
‡ This would actually be quite problematic if it could occur because glibc seemingly only attempts to use /dev/ptmx when creating new terminals and thus most terminal managers (including tmux) and shell tools (including sudo -- but not su) would fail to start and thus bring the system to a halt. setupPtmx does add a symlink to /dev/pts/ptmx afterwards but on some systems the mode of the host /dev/pts/ptmx is set to 0o000 which would still cause the same DoS issue.
Patches
This issue has been patched in runc 1.3.6, runc 1.4.3, and runc 1.5.0-rc.3.
Workarounds
Using user namespaces restricts this attack fairly significantly such that the attacker can only create/delete inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actual user on the host (such as with rootless containers that don't use /etc/sub[ug]id), this in practice means that an attacker would only be able to create or delete inodes in world-writable directories.
LSMs can restrict the scope of where in the host filesystem runc can be tricked into operating on, though how much this helps is questionable. The default container_runtime_t SELinux label rules (or custom AppArmor rules for the host runc context) may restrict the scope where these filesystem operations can operate on, but we have not done an in-depth analysis on the impact of those kinds of LSM protections.
runc thanks "Davias" for initially finding and reporting this issue. The same underlying issue (with varying levels of completeness) was later reported by Arthur Chan (@arthurscchan from Ada Logics), Junyi Liu (@mosskappa), and Derek Manzella (@Dmanzella).
go.opentelemetry.io/otel1.41.0 (golang)
pkg:golang/go.opentelemetry.io/otel@1.41.0
Affected range
>=1.41.0 <1.42.0
Fixed version
1.42.0
EPSS Score
0.336%
EPSS Percentile
26th percentile
Description
Opentelemetry-go's baggage parsing no longer caps raw header length in go.opentelemetry.io/otel
An issue in Kata with Cloud Hypervisor allows a user of the container to modify the file system used by the Guest micro VM ultimately achieving arbitrary code execution as root in said VM. The current understinding is this doesn’t impact the security of the Host or of other containers / VMs running on that Host (note that arm64 QEMU lacks NVDIMM read-only support: It is believed that until the upstream QEMU gains this capability, a guest write could reach the image file).
Details
Linux virtio-pmem
The virtio-pmem probe path always registers the region as a generic pagemap that supports asynchronous flushes, but it never marks the region as read-only. Only the ND_REGION_PAGEMAP and ND_REGION_ASYNC bits are set before the region is created, so nd_region->ro always stays cleared and the block device is left writable.
Later, pmem_attach_disk() wires the region into the block layer with full read/write semantics – the block device operations call pmem_do_write() which performs cache-flushed memcpy operations directly into the host-provided shared memory window. nvdimm_check_and_set_ro() would set the disk read-only if the region had been flagged as such, but because virtio_pmem never sets that flag, the helper becomes a no-op.
Cloud-Hypervisor virtio_pmem discard_writes=on causes the file backing the virtio-pmem device to be opened read-only and mapped with MAP_PRIVATE rather than MAP_SHARED. That combination means the guest can modify the private copy of the mapped pages, but those modifications never propagate back to the underlying file. The guest (and Cloud Hypervisor process) will still read the modified data because it lives in the private copy of the mapping, so write-then-read sequences appear to succeed even though nothing is persisted. Once the mapping is dropped or the VM is restarted, those copy-on-write changes disappear, leaving the backing file unchanged.
Kata /dev/pmem0
Kata boots each pod/VM by DAX-mapping a read-only guest image from the host into the VM and telling the guest kernel to mount the resulting /dev/pmem* device as its root filesystem.
Since DAX maps the backing file directly into guest memory, there is no way for the hypervisor to intercept or reject individual stores, so a container with sufficient permissions can open /dev/pmem0 and observe its own writes until the VM is rebooted or the cache is dropped.
PoC
When putting all this together, this means that a user of a Container (not necessarily privileged, we don’t need CAP_SYS_ADMIN, but we need CAP_MKNOD) can modify the Guest OS filesystem, replacing libraries or binaries to achieve arbitrary code execution outside of the Container. This requires computing offsets of files within the device, which requires information like the partition start sector, sector size in bytes, the filesystem block size, and the physical block index of the file.
To achieve execution on the Guest, I replaced /usr/bin/systemd-tmpfiles with a connect-back shell to localhost: timers end up executing 15min after boot.
I use debugfs to not require mounting privileges and work directly with the filesystem on /dev/pmem0p1 to get the absolute offset of the file to modify in the device.
If you want a simpler PoC, just dd write something into /dev/pmem0 and observe it's dd readable until discarded.
An issue in Kata with Cloud Hypervisor allows a user of the container to modify the file system used by the Guest micro VM ultimately achieving arbitrary code execution as root in said VM. The current understinding is this doesn’t impact the security of the Host or of other containers / VMs running on that Host (note that arm64 QEMU lacks NVDIMM read-only support: It is believed that until the upstream QEMU gains this capability, a guest write could reach the image file).
Details
Linux virtio-pmem
The virtio-pmem probe path always registers the region as a generic pagemap that supports asynchronous flushes, but it never marks the region as read-only. Only the ND_REGION_PAGEMAP and ND_REGION_ASYNC bits are set before the region is created, so nd_region->ro always stays cleared and the block device is left writable.
Later, pmem_attach_disk() wires the region into the block layer with full read/write semantics – the block device operations call pmem_do_write() which performs cache-flushed memcpy operations directly into the host-provided shared memory window. nvdimm_check_and_set_ro() would set the disk read-only if the region had been flagged as such, but because virtio_pmem never sets that flag, the helper becomes a no-op.
Cloud-Hypervisor virtio_pmem discard_writes=on causes the file backing the virtio-pmem device to be opened read-only and mapped with MAP_PRIVATE rather than MAP_SHARED. That combination means the guest can modify the private copy of the mapped pages, but those modifications never propagate back to the underlying file. The guest (and Cloud Hypervisor process) will still read the modified data because it lives in the private copy of the mapping, so write-then-read sequences appear to succeed even though nothing is persisted. Once the mapping is dropped or the VM is restarted, those copy-on-write changes disappear, leaving the backing file unchanged.
Kata /dev/pmem0
Kata boots each pod/VM by DAX-mapping a read-only guest image from the host into the VM and telling the guest kernel to mount the resulting /dev/pmem* device as its root filesystem.
Since DAX maps the backing file directly into guest memory, there is no way for the hypervisor to intercept or reject individual stores, so a container with sufficient permissions can open /dev/pmem0 and observe its own writes until the VM is rebooted or the cache is dropped.
PoC
When putting all this together, this means that a user of a Container (not necessarily privileged, we don’t need CAP_SYS_ADMIN, but we need CAP_MKNOD) can modify the Guest OS filesystem, replacing libraries or binaries to achieve arbitrary code execution outside of the Container. This requires computing offsets of files within the device, which requires information like the partition start sector, sector size in bytes, the filesystem block size, and the physical block index of the file.
To achieve execution on the Guest, I replaced /usr/bin/systemd-tmpfiles with a connect-back shell to localhost: timers end up executing 15min after boot.
I use debugfs to not require mounting privileges and work directly with the filesystem on /dev/pmem0p1 to get the absolute offset of the file to modify in the device.
If you want a simpler PoC, just dd write something into /dev/pmem0 and observe it's dd readable until discarded.
The mongo-go-driver repository contains CGo bindings for GSSAPI (Kerberos) authentication on Linux and macOS. The C wrapper implementation contains a heap out-of-bounds read vulnerability due to incorrect assumptions about string termination in the GSSAPI standard. Since GSSAPI buffers are not guaranteed to be null-terminated or have extra padding, this results in reading one byte past the allocated heap buffer.
github.com/sigstore/sigstore1.10.3 (golang)
pkg:golang/github.com/sigstore/sigstore@1.10.3
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Affected range
<=1.10.3
Fixed version
1.10.4
CVSS Score
5.8
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:H/A:N
EPSS Score
0.363%
EPSS Percentile
29th percentile
Description
Summary
The legacy TUF client pkg/tuf/client.go, which supports caching target files to disk, constructs a filesystem path by joining a cache base directory with a target name sourced from signed target metadata, but it does not validate that the resulting path stays within the cache base directory.
Note that this should only affect clients that are directly using the TUF client in sigstore/sigstore or are using an older version of Cosign. As this TUF client implementation is deprecated, users should migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf as soon as possible.
Note that this does not affect users of the public Sigstore deployment, where TUF metadata is validated by a quorum of trusted collaborators.
Impact
A malicious TUF repository can trigger arbitrary file overwriting, limited to the permissions that the calling process has.
Workarounds
Users can disable disk caching for the legacy client by setting SIGSTORE_NO_CACHE=true in the environment, migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf, or upgrade to the latest sigstore/sigstore release.
golang.org/x/sys0.41.0 (golang)
pkg:golang/golang.org/x/sys@0.41.0
Affected range
<0.44.0
Fixed version
0.44.0
EPSS Score
0.114%
EPSS Percentile
2nd percentile
Description
NewNTUnicodeString does not check for string length overflow. When provided with a string that overflows the maximum size of a NTUnicodeString (a 16-bit number of bytes), it returns a truncated string rather than an error.
github.com/go-chi/chi/v55.2.5 (golang)
pkg:golang/github.com/go-chi/chi@5.2.5#v5
Affected range
<5.3.0
Fixed version
5.3.0
Description
Chi's RealIP Middleware allows IP spoofing via unvalidated X-Forwarded-For header in github.com/go-chi/chi
Affected range
<5.3.0
Fixed version
5.3.0
Description
Chi Middleware vulnerable to IP spoofing via X-Forwarded-For header in github.com/go-chi/chi
Affected range
>=5.2.1 <5.3.0
Fixed version
5.3.0
Description
Chi has an IP spoofing vulnerability in middleware.RealIP in github.com/go-chi/chi
github.com/klauspost/compress1.18.3 (golang)
pkg:golang/github.com/klauspost/compress@1.18.3
Affected range
>=1.16.0 <1.18.7
Fixed version
1.18.7
Description
Providing a specially crafted dictionary to s2.NewDict and using it to encode data can make the encoder read out of bounds.
golang.org/x/text0.34.0 (golang)
pkg:golang/golang.org/x/text@0.34.0
Affected range
<0.39.0
Fixed version
0.39.0
EPSS Score
0.475%
EPSS Percentile
39th percentile
Description
A norm.Iter can enter an infinite loop when handling input containing invalid UTF-8 bytes.
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
uniget-bot
changed the title
This PR contains the following updates:
1.36.3→1.36.5Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Release Notes
cri-o/cri-o (cri-o)
v1.36.5Compare Source
CRI-O v1.36.5
The release notes have been generated for the commit range
v1.36.4...v1.36.5 on Wed, 02 Sep 2026 08:47:31 UTC.
Downloads
Download one of our static release bundles via our Google Cloud Bucket:
The OpenVEX report for this release is available at:
The SLSA provenance attestation for this release is available at:
All release artifacts (bundles, SBOMs, VEX, and provenance) are also available as signed OCI artifacts at
ghcr.io/cri-o/bundle:v1.36.5.To verify the artifact signatures via cosign, run:
To verify the bill of materials (SBOM) in SPDX format using the bom tool, run:
To verify the OpenVEX vulnerability report, run:
To verify the SLSA provenance attestation, run:
Changelog since v1.36.4
Changes by Kind
Bug or Regression
Dependencies
Added
Nothing has changed.
Changed
Nothing has changed.
Removed
Nothing has changed.
v1.36.4Compare Source
CRI-O v1.36.4
The release notes have been generated for the commit range
v1.36.3...v1.36.4 on Mon, 24 Aug 2026 16:51:10 UTC.
Downloads
Download one of our static release bundles via our Google Cloud Bucket:
The OpenVEX report for this release is available at:
The SLSA provenance attestation for this release is available at:
All release artifacts (bundles, SBOMs, VEX, and provenance) are also available as signed OCI artifacts at
ghcr.io/cri-o/bundle:v1.36.4.To verify the artifact signatures via cosign, run:
To verify the bill of materials (SBOM) in SPDX format using the bom tool, run:
To verify the OpenVEX vulnerability report, run:
To verify the SLSA provenance attestation, run:
Changelog since v1.36.3
Changes by Kind
Feature
Bug or Regression
Dependencies
Added
Nothing has changed.
Changed
Nothing has changed.
Removed
Nothing has 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.