Snyk test report
- quay.io/minio/aistor/minio:RELEASE.2026-06-06T02-44-06Z/minio/aistor/minio (rpm)
- quay.io/minio/aistor/minio:RELEASE.2026-06-06T02-44-06Z/minio/mc//usr/bin/mc (gomodules)
- quay.io/minio/aistor/minio:RELEASE.2026-06-06T02-44-06Z/minio/minio//usr/bin/minio (gomodules)
Improper Authentication
Detailed paths
Overview
Affected versions of this package are vulnerable to Improper Authentication via the ToASCII and ToUnicode functions. An attacker can bypass hostname validation by submitting Punycode-encoded labels that decode to ASCII-only labels, potentially leading to privilege escalation in applications that rely on these functions for security checks.
Note: The fix depends on the Go toolchain in use having Unicode version 16 or later, which is planned for the 1.27 release.
Remediation
Upgrade golang.org/x/net/idna to version 0.54.0 or higher.
References
Resources Downloaded over Insecure Protocol
Detailed paths
Overview
Affected versions of this package are vulnerable to Resources Downloaded over Insecure Protocol.
Go Vulnerability Report:
A malicious module proxy can exploit a flaw in the go command's validation of module checksums to bypass checksum database validation. This vulnerability affects any user using an untrusted module proxy (GOMODPROXY) or checksum database (GOSUMDB). A malicious module proxy can serve altered versions of the Go toolchain. When selecting a different version of the Go toolchain than the currently installed toolchain (due to the GOTOOLCHAIN environment variable, or a go.work or go.mod with a toolchain line), the go command will download and execute a toolchain provided by the module proxy. A malicious module proxy can bypass checksum database validation for this downloaded toolchain. Since this vulnerability affects the security of toolchain downloads, setting GOTOOLCHAIN to a fixed version is not sufficient. You must upgrade your base Go toolchain. The go tool always validates the hash of a toolchain before executing it, so fixed versions will refuse to execute any cached, altered versions of the toolchain. The go tool trusts go.sum files to contain accurate hashes of the current module's dependencies. A malicious proxy exploiting this vulnerability to serve an altered module will have caused an incorrect hash to be recorded in the go.sum. Users who have configured a non-trusted GOPROXY can determine if they have been affected by running "rm go.sum ; go mod tidy ; go mod verify", which will revalidate all dependencies of the current module. The specific flaw in more detail: The go command consults the checksum database to validate downloaded modules, when a module is not listed in the go.sum file. It verifies that the module hash reported by the checksum database matches the hash of the downloaded module. If, however, the checksum database returns a successful response that contains no entry for the module, the go command incorrectly permitted validation to succeed. A module proxy may mirror or proxy the checksum database, in which case the go command will not connect to the checksum database directly. Checksums reported by the checksum database are cryptographically signed, so a malicious proxy cannot alter the reported checksum for a module. However, a proxy which returns an empty checksum response, or a checksum response for an unrelated module, could cause the go command to proceed as if a downloaded module has been validated.
Remediation
Upgrade std/cmd/go to version 1.25.10, 1.26.3 or higher.
References
Directory Traversal
Detailed paths
Overview
Affected versions of this package are vulnerable to Directory Traversal.
Go Vulnerability Report:
The "go tool pack" subcommand (usually used only by the compiler as an internal tool with known-good inputs) does not sanitize output filenames. Extracting a malicious archive file with the "pack" subcommand can write files to arbitrary locations on the filesystem.
Details
A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.
Directory Traversal vulnerabilities can be generally divided into two types:
- Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.
st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.
If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.
curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa
Note %2e is the URL encoded version of . (dot).
- Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as
Zip-Slip.
One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.
The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:
2018-04-15 22:04:29 ..... 19 19 good.txt
2018-04-15 22:04:42 ..... 20 20 ../../../../../../root/.ssh/authorized_keys
Remediation
Upgrade std/cmd/go to version 1.25.10, 1.26.3 or higher.
References
Denial of Service (DoS)
Detailed paths
Overview
std/crypto/tls is a Go standard library package std/crypto/tls
Affected versions of this package are vulnerable to Denial of Service (DoS).
Go Vulnerability Report:
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.
Details
Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.
Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.
One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.
When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.
Two common types of DoS vulnerabilities:
High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.
Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm
wspackage
Remediation
Upgrade std/crypto/tls to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/crypto/x509 is a Go standard library package std/crypto/x509
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
(*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.
Remediation
Upgrade std/crypto/x509 to version 1.25.11, 1.26.4 or higher.
References
Uncontrolled Recursion
Detailed paths
Overview
std/encoding/asn1 is a Go standard library package std/encoding/asn1
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
Enforce a recursion limit in Unmarshal to prevent stack exhaustion when parsing deeply-nested, recursive structures.
Remediation
Upgrade std/encoding/asn1 to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.
References
Uncontrolled Recursion
Detailed paths
Overview
std/encoding/xml is a Go standard library package std/encoding/xml
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
Previously, DecodeElement would reset the depth counter causing it to never fire; this could lead to stack exhaustion.
Remediation
Upgrade std/encoding/xml to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/mime is a Go standard library package std/mime
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
Decoding a maliciously-crafted MIME header containing many invalid encoded-words can consume excessive CPU.
Remediation
Upgrade std/mime to version 1.25.11, 1.26.4 or higher.
References
Double Free
Detailed paths
Overview
std/net is a Go standard library package std/net
Affected versions of this package are vulnerable to Double Free.
Go Vulnerability Report:
When using LookupCNAME with the cgo DNS resolver, a very long CNAME response can trigger a double-free of C memory and a crash.
Remediation
Upgrade std/net to version 1.25.10, 1.26.3 or higher.
References
Uncaught Exception
Detailed paths
Overview
std/net is a Go standard library package std/net
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
The Dial and LookupPort functions panic on Windows when provided with an input containing a NUL (0).
Remediation
Upgrade std/net to version 1.25.10, 1.26.3 or higher.
References
Uncaught Exception
Detailed paths
Overview
std/net is a Go standard library package std/net
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.
Remediation
Upgrade std/net to version 1.26.6, 1.27.0-rc.3 or higher.
References
Infinite loop
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to Infinite loop.
Go Vulnerability Report:
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.
Remediation
Upgrade std/net/http to version 1.25.10, 1.26.3 or higher.
References
Denial of Service (DoS)
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to Denial of Service (DoS).
Go Vulnerability Report:
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.
Details
Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.
Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.
One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.
When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.
Two common types of DoS vulnerabilities:
High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.
Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm
wspackage
Remediation
Upgrade std/net/http to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/mail is a Go standard library package std/net/mail
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
Well-crafted inputs reaching ParseAddress, ParseAddressList, and ParseDate were able to trigger excessive CPU exhaustion and memory allocations.
Remediation
Upgrade std/net/mail to version 1.25.10, 1.26.3 or higher.
References
Denial of Service (DoS)
Detailed paths
Overview
std/net/url is a Go standard library package std/net/url
Affected versions of this package are vulnerable to Denial of Service (DoS).
Go Vulnerability Report:
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.
Details
Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.
Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.
One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.
When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.
Two common types of DoS vulnerabilities:
High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.
Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm
wspackage
Remediation
Upgrade std/net/url to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.
References
Symlink Attack
Detailed paths
Overview
std/os is a Go standard library package std/os
Affected versions of this package are vulnerable to Symlink Attack.
Go Vulnerability Report:
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.
Remediation
Upgrade std/os to version 1.25.12, 1.26.5, 1.27.0-rc.2 or higher.
References
Time-of-check Time-of-use (TOCTOU)
Detailed paths
NVD Description
Note: Versions mentioned in the description apply only to the upstream libacl package and not the libacl package as distributed by RHEL.
See How to fix? for RHEL:9 relevant fixed versions and status.
acl before version 2.4.0 contains a time-of-check to time-of-use (TOCTOU) race condition vulnerability that allows local attackers to escalate privileges by replacing a pathname component with a symbolic link between an lstat() check and subsequent symlink-following operations such as stat(), chown(), chmod(), acl_get_file(), and acl_set_file(). Attackers who control a pathname component can redirect file access control list operations to arbitrary files when getfacl, setfacl, or chacl is invoked by a privileged process over an attacker-controlled path, resulting in local privilege escalation.
Remediation
Upgrade RHEL:9 libacl to version 0:2.4.0-1.el9_8 or higher.
This issue was patched in RHSA-2026:42736.
References
- https://access.redhat.com/security/cve/CVE-2026-54370
- https://cgit.git.savannah.nongnu.org/cgit/acl.git/commit/?id=24a227d0ab8576612194f8a56c2314389adc74a5
- https://cgit.git.savannah.nongnu.org/cgit/acl.git/commit/?id=3589787cd589b34bdd9265936e17190b6d3f17d1
- https://www.vulncheck.com/advisories/acl-toctou-symlink-traversal-via-getfacl-setfacl-chacl
Link Following
Detailed paths
NVD Description
Note: Versions mentioned in the description apply only to the upstream libacl package and not the libacl package as distributed by RHEL.
See How to fix? for RHEL:9 relevant fixed versions and status.
acl before version 2.4.0 contains a symlink traversal vulnerability in the libacl pathname-based functions acl_get_file(), acl_set_file(), acl_extended_file(), and acl_delete_def_file() that allows local attackers to escalate privileges by replacing any pathname component with a symbolic link. Attackers who control any component of a pathname processed by a privileged caller can redirect ACL read or write operations to arbitrary files or directories, enabling unauthorized manipulation of access control lists and local privilege escalation.
Remediation
Upgrade RHEL:9 libacl to version 0:2.4.0-1.el9_8 or higher.
This issue was patched in RHSA-2026:42736.
References
- https://access.redhat.com/security/cve/CVE-2026-54369
- https://cgit.git.savannah.nongnu.org/cgit/acl.git/commit/?id=24a227d0ab8576612194f8a56c2314389adc74a5
- https://cgit.git.savannah.nongnu.org/cgit/acl.git/commit/?id=3589787cd589b34bdd9265936e17190b6d3f17d1
- https://www.vulncheck.com/advisories/acl-symlink-traversal-privilege-escalation-via-libacl-functions
- https://access.redhat.com/errata/RHSA-2026:42736
- https://bugzilla.redhat.com/show_bug.cgi?id=2490277
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-54369.json
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the HTTP/2 DATA frame receive buffer handling, where each received fragment incurs per-fragment tracking and queue allocation overhead even while staying within the configured flow-control windows. An attacker can drive the process to an OutOfMemory condition or a runtime panic by opening gRPC streams and fragmenting payloads into millions of tiny HTTP/2 DATA frames, such as 1 byte each, across many concurrent multiplexed streams. This requires only the ability to establish gRPC stream connections to the server.
Remediation
Upgrade google.golang.org/grpc/mem to version 1.83.1 or higher.
References
Uncaught Exception
Detailed paths
Overview
Affected versions of this package are vulnerable to Uncaught Exception through the HTTP/2 header processing path in internal/transport/http2_server.go and internal/xds/server/routing.go. An attacker can crash the server by sending a gRPC request that omits both the :authority and Host headers. In xds.NewGRPCServer() deployments, that malformed request reaches the xDS routing interceptor, which expects an authority value and then indexes into an empty header slice. The resulting panic terminates the server process, causing a complete outage for clients connected to that gRPC server.
Remediation
Upgrade google.golang.org/grpc/internal/xds/server to version 1.82.2, 1.83.2 or higher.
References
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Issue
- GitHub PR
- GitHub PR
- GitHub PR
- Maintainer's Advisory
Incorrect Authorization
Detailed paths
Overview
Affected versions of this package are vulnerable to Incorrect Authorization in the processing of xDS RBAC policies and HTTP/2 transport handling. An attacker can gain unauthorized access to protected services or cause denial of service by exploiting improper handling of unsupported fields in policy matchers, bypassing rapid reset mitigations, or triggering server panics through crafted policy updates.
Note: This advisory refers to several vulnerabilities as aggregated by the maintainer. For an exact breakdown and affected code, see the Maintainer's referenced advisory and commit.
Workaround
This vulnerability can be mitigated by ensuring xDS management servers do not push RBAC policies with unsupported fields or NOT rules wrapping unhandled fields, and by configuring upstream reverse proxies or load balancers with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.
Remediation
Upgrade google.golang.org/grpc/internal/xds/rbac to version 1.82.1 or higher.
References
Incorrect Authorization
Detailed paths
Overview
Affected versions of this package are vulnerable to Incorrect Authorization in the processing of xDS RBAC policies and HTTP/2 transport handling. An attacker can gain unauthorized access to protected services or cause denial of service by exploiting improper handling of unsupported fields in policy matchers, bypassing rapid reset mitigations, or triggering server panics through crafted policy updates.
Note: This advisory refers to several vulnerabilities as aggregated by the maintainer. For an exact breakdown and affected code, see the Maintainer's referenced advisory and commit.
Workaround
This vulnerability can be mitigated by ensuring xDS management servers do not push RBAC policies with unsupported fields or NOT rules wrapping unhandled fields, and by configuring upstream reverse proxies or load balancers with strict HTTP/2 max_concurrent_streams limits and active rate limiting on RST_STREAM frequency per connection.
Remediation
Upgrade google.golang.org/grpc/internal/transport to version 1.82.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the HTTP/2 DATA frame receive buffer handling, where each received fragment incurs per-fragment tracking and queue allocation overhead even while staying within the configured flow-control windows. An attacker can drive the process to an OutOfMemory condition or a runtime panic by opening gRPC streams and fragmenting payloads into millions of tiny HTTP/2 DATA frames, such as 1 byte each, across many concurrent multiplexed streams. This requires only the ability to establish gRPC stream connections to the server.
Remediation
Upgrade google.golang.org/grpc/internal/transport to version 1.83.1 or higher.
References
Uncaught Exception
Detailed paths
Overview
Affected versions of this package are vulnerable to Uncaught Exception through the HTTP/2 header processing path in internal/transport/http2_server.go and internal/xds/server/routing.go. An attacker can crash the server by sending a gRPC request that omits both the :authority and Host headers. In xds.NewGRPCServer() deployments, that malformed request reaches the xDS routing interceptor, which expects an authority value and then indexes into an empty header slice. The resulting panic terminates the server process, causing a complete outage for clients connected to that gRPC server.
Remediation
Upgrade google.golang.org/grpc/internal/transport to version 1.82.2, 1.83.2 or higher.
References
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Issue
- GitHub PR
- GitHub PR
- GitHub PR
- Maintainer's Advisory
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the HTTP/2 DATA frame receive buffer handling, where each received fragment incurs per-fragment tracking and queue allocation overhead even while staying within the configured flow-control windows. An attacker can drive the process to an OutOfMemory condition or a runtime panic by opening gRPC streams and fragmenting payloads into millions of tiny HTTP/2 DATA frames, such as 1 byte each, across many concurrent multiplexed streams. This requires only the ability to establish gRPC stream connections to the server.
Remediation
Upgrade google.golang.org/grpc/internal/mem to version 1.83.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the HTTP/2 DATA frame receive buffer handling, where each received fragment incurs per-fragment tracking and queue allocation overhead even while staying within the configured flow-control windows. An attacker can drive the process to an OutOfMemory condition or a runtime panic by opening gRPC streams and fragmenting payloads into millions of tiny HTTP/2 DATA frames, such as 1 byte each, across many concurrent multiplexed streams. This requires only the ability to establish gRPC stream connections to the server.
Remediation
Upgrade google.golang.org/grpc/internal/envconfig to version 1.83.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
golang.org/x/crypto/ssh is a SSH client and server
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in its connection multiplexing, reached through Dial, NewClientConn, NewControlClientConn, and NewServerConn, which buffers unhandled messages that fall outside the RFC 4254 channel and global-request handling instead of treating them as protocol errors. A malicious peer can deadlock the entire SSH connection by sending unexpected messages once a channel has been established. This requires a completed handshake and an open SSH channel with the attacker as the peer.
Remediation
Upgrade golang.org/x/crypto/ssh to version 0.56.0 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
golang.org/x/crypto/ssh is a SSH client and server
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the connection multiplexer's channel handling (the mux chanList), reached through Dial, NewClientConn, NewControlClientConn, and NewServerConn, where a channel that is registered but not yet established has its incomingRequests queue flooded without bound. A malicious peer can deadlock the entire SSH connection by flooding channel request packets for a channel before it becomes established. This requires the attacker to participate in an SSH connection with the victim over the library.
Remediation
Upgrade golang.org/x/crypto/ssh to version 0.56.0 or higher.
References
Open Redirect
Detailed paths
Overview
Affected versions of this package are vulnerable to Open Redirect in the RedirectHandler function. An attacker can obtain sensitive information such as session cookies, proxy credentials, and API keys by inducing a cross-host or cross-scheme redirect, causing these headers to be forwarded to an attacker-controlled server.
Remediation
Upgrade github.com/microsoft/kiota-http-go to version 1.5.5 or higher.
References
Integer Overflow
Detailed paths
Overview
Affected versions of this package are vulnerable to Integer Overflow leading to an out-of-bounds write in the s2.NewDict() function in s2/dict.go, which reads a uvarint and converts it to int without checking whether it exceeds MaxInt64. An attacker can crash the process with a segmentation fault by supplying S2 dictionary data whose repeat-index uvarint exceeds MaxInt64, which becomes a negative int that bypasses the index validation and drives out-of-bounds arithmetic through unsafe.Pointer in Dict.Encode(). Exploitation requires the application to build an S2 dictionary from attacker-controlled data with s2.NewDict() and then call Dict.Encode() on input of at least 32 bytes.
Remediation
Upgrade github.com/klauspost/compress/s2 to version 1.18.7 or higher.
References
Integer Overflow or Wraparound
Detailed paths
Overview
Affected versions of this package are vulnerable to Integer Overflow or Wraparound in the decoding process. An attacker can cause application crashes or bypass memory allocation limits by supplying specially crafted Avro data that exploits integer arithmetic errors during decoding operations. This can result in panics, memory allocation issues, or incorrect data processing.
Remediation
There is no fixed version for github.com/hamba/avro/v2/ocf.
References
Infinite loop
Detailed paths
Overview
Affected versions of this package are vulnerable to Infinite loop through the Avro Decoder process. An attacker can exhaust CPU resources by providing a specially crafted payload with a large block-count value, causing the decoder to perform excessive iterations before propagating an error.
Remediation
There is no fixed version for github.com/hamba/avro/v2.
References
Integer Overflow or Wraparound
Detailed paths
Overview
Affected versions of this package are vulnerable to Integer Overflow or Wraparound in the decoding process. An attacker can cause application crashes or bypass memory allocation limits by supplying specially crafted Avro data that exploits integer arithmetic errors during decoding operations. This can result in panics, memory allocation issues, or incorrect data processing.
Remediation
There is no fixed version for github.com/hamba/avro/v2.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the mapDecoder.Decode and mapDecoderUnmarshaler.Decode methods in codec_map.go, which use the attacker-controlled map block element count both to pre-size the destination map and as the read loop bound with no per-block or cumulative upper limit. An attacker can exhaust process memory and terminate the process with an out-of-memory error by supplying Avro data whose map block header declares a very large element count, or by splitting a large map across many small blocks that accumulate past any per-block threshold. Exploitation requires the application to decode untrusted Avro data containing map structures.
Workaround
This vulnerability can be avoided by decoding untrusted Avro in a memory-constrained child process or cgroup, bounding any oversized map allocation so it cannot exhaust the whole host.
Remediation
There is no fixed version for github.com/hamba/avro/v2.
References
Uncontrolled Recursion
Detailed paths
Overview
Affected versions of this package are vulnerable to Uncontrolled Recursion in the ordered-JSON marshal/unmarshal paths through the jsonutils/adapters/stdlib/json and jsonutils/adapters/easyjson/json ordered map handlers. An attacker can crash the process by sending a deeply nested JSON document to ReadJSON/JSONMapSlice.UnmarshalJSON or by causing WriteJSON/JSONMapSlice.MarshalJSON to process an equally deep in-memory JSONMapSlice. The unbounded recursion exhausts the goroutine stack and triggers a non-recoverable fatal error: stack overflow, terminating the serving process and dropping in-flight requests.
Remediation
Upgrade github.com/go-openapi/swag/jsonutils/adapters/stdlib/json to version 0.27.1 or higher.
References
Integer Overflow or Wraparound
Detailed paths
Overview
github.com/apache/thrift/lib/go/thrift is a Go implementation of the Apache Thrift library.
Affected versions of this package are vulnerable to Integer Overflow or Wraparound due to improper handling of integer values in the TFramedTransport() function on 32-bit architectures. An attacker can cause resource exhaustion or unexpected behavior by sending specially crafted input that triggers an integer overflow.
Note:
- As explained in fix PR Description, the initial fix, which was introduced in 0.23.0, was incomplete and could fail on 32-bit systems. While this version partially resolves the issue, we recommend using 0.24.0, which includes the complete patch.
Remediation
Upgrade github.com/apache/thrift/lib/go/thrift to version 0.24.0 or higher.
References
- Apache Mailing List
- GitHub Commit
- GitHub Commit (Issue introduced in)
- GitHub PR
- OSS Security Advisory
- Red Hat Bugzilla Bug
Improper Handling of Highly Compressed Data (Data Amplification)
Detailed paths
Overview
github.com/apache/thrift/lib/go/thrift is a Go implementation of the Apache Thrift library.
Affected versions of this package are vulnerable to Improper Handling of Highly Compressed Data (Data Amplification) via the TZlibTransport read paths in the C++, Java, Python, and Go bindings. An attacker can exhaust memory or trigger a denial of service by sending a small zlib-compressed payload that expands beyond the transport’s intended message-size limits during decompression. The vulnerable code reads decompressed bytes without consistently counting them against the configured maximum message size, so repeated reads through TZlibTransport can keep accepting output from a highly compressed stream even after the limit should have been exceeded. This breaks applications that rely on Thrift’s message-size enforcement to cap untrusted input before it is fully decompressed.
Notes
- In the Java and Go bindings, the vulnerable path is the stream-oriented
read()behavior ofTZlibTransport; applications that only write-through or otherwise avoid reading decompressed data are not exposed through this bug. - The Python bindings expose an explicit decompressed-size limit parameter, and the default cap in Python tracks
HARD_MAX_FRAME_SIZE; deployments that override those constructors may see a different effective ceiling.
Remediation
Upgrade github.com/apache/thrift/lib/go/thrift to version 0.24.0 or higher.
References
- Apache Security Advisory
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- OSS Security Advisory
- Red Hat Bugzilla Bug
Infinite loop
Detailed paths
Overview
github.com/apache/thrift/lib/go/thrift is a Go implementation of the Apache Thrift library.
Affected versions of this package are vulnerable to Infinite loop in TCompactProtocol varint decoding, which reads continuation bytes without enforcing a maximum byte count. An attacker can hang the process deserializing a message by sending a TCompactProtocol varint whose continuation bit stays set across an unbounded run of bytes. This requires the application to deserialize attacker-controlled TCompactProtocol input.
Remediation
Upgrade github.com/apache/thrift/lib/go/thrift to version 0.24.0 or higher.
References
Data Amplification
Detailed paths
Overview
github.com/apache/thrift/lib/go/thrift is a Go implementation of the Apache Thrift library.
Affected versions of this package are vulnerable to Data Amplification in THeaderTransport.parseHeaders() in lib/go/thrift/header_transport.go, which attaches a ZLIB reader to the frame whenever the header block lists that transform and places no bound on the inflated output, although ReadFrame already holds the frame itself to MaxFrameSize as it comes off the wire. An attacker can exhaust the process memory by sending a frame that stays within the wire size limit but whose ZLIB payload inflates far beyond it. This requires the application to use the Go bindings with THeaderTransport, and the transform is selected per frame by the sender in the header block rather than by the receiving application's configuration, so an application that never enables ZLIB itself still inflates frames that ask for it.
Remediation
Upgrade github.com/apache/thrift/lib/go/thrift to version 0.25.0 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
github.com/apache/thrift/lib/go/thrift is a Go implementation of the Apache Thrift library.
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in TFramedTransport.Read() in lib/go/thrift/framed_transport.go and THeaderTransport.Read() in lib/go/thrift/header_transport.go, each of which responds to a buffered frame yielding no payload bytes by reading the next frame and calling itself again rather than looping, so nothing bounds the depth. An attacker can terminate the process by sending a stream of frames that carry no payload, costing 4 bytes each in TFramedTransport as a declared size of zero and 18 bytes each in THeaderTransport as a header block that fills the frame, until the Go stack limit is reached as a fatal error that recover() cannot intercept, so a server that otherwise contains per connection panics dies in full. This requires only that the application use the Go bindings with either transport, with no configuration or authentication step in the way, and a single connection suffices, since each stack frame costs the attacker a handful of bytes.
Remediation
Upgrade github.com/apache/thrift/lib/go/thrift to version 0.25.0 or higher.