Improper Encoding or Escaping of Output
Detailed paths
Overview
std/html/template is a Go standard library package std/html/template
Affected versions of this package are vulnerable to Improper Encoding or Escaping of Output.
Go Vulnerability Report:
Not all valid JavaScript whitespace characters are considered to be whitespace. Templates containing whitespace characters outside of the character set "\t\n\f\r\u0020\u2028\u2029" in JavaScript contexts that also contain actions may not be properly sanitized during execution.
Remediation
Upgrade std/html/template to version 1.19.9, 1.20.4 or higher.
References
Cross-site Scripting (XSS)
Detailed paths
Overview
std/html/template is a Go standard library package std/html/template
Affected versions of this package are vulnerable to Cross-site Scripting (XSS).
Go Vulnerability Report:
Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected.Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template.As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml.With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21.Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution.
Details
Cross-site scripting (or XSS) is a code vulnerability that occurs when an attacker “injects” a malicious script into an otherwise trusted website. The injected script gets downloaded and executed by the end user’s browser when the user interacts with the compromised website.
This is done by escaping the context of the web application; the web application then delivers that data to its users along with other trusted dynamic content, without validating it. The browser unknowingly executes malicious script on the client side (through client-side languages; usually JavaScript or HTML) in order to perform actions that are otherwise typically blocked by the browser’s Same Origin Policy.
Injecting malicious code is the most prevalent manner by which XSS is exploited; for this reason, escaping characters in order to prevent this manipulation is the top method for securing code against this vulnerability.
Escaping means that the application is coded to mark key characters, and particularly key characters included in user input, to prevent those characters from being interpreted in a dangerous context. For example, in HTML, < can be coded as < and > can be coded as > in order to be interpreted and displayed as themselves in text, while within the code itself, they are used for HTML tags. If malicious content is injected into an application that escapes special characters and that malicious content uses < and > as HTML tags, those characters are nonetheless not interpreted as HTML tags by the browser if they’ve been correctly escaped in the application code and in this way the attempted attack is diverted.
The most prominent use of XSS is to steal cookies (source: OWASP HttpOnly) and hijack user sessions, but XSS exploits have been used to expose sensitive information, enable access to privileged services and functionality and deliver malware.
Types of attacks
There are a few methods by which XSS can be manipulated:
| Type | Origin | Description |
|---|---|---|
| Stored | Server | The malicious code is inserted in the application (usually as a link) by the attacker. The code is activated every time a user clicks the link. |
| Reflected | Server | The attacker delivers a malicious link externally from the vulnerable web site application to a user. When clicked, malicious code is sent to the vulnerable web site, which reflects the attack back to the user’s browser. |
| DOM-based | Client | The attacker forces the user’s browser to render a malicious page. The data in the page itself delivers the cross-site scripting data. |
| Mutated | The attacker injects code that appears safe, but is then rewritten and modified by the browser, while parsing the markup. An example is rebalancing unclosed quotation marks or even adding quotation marks to unquoted parameters. |
Affected environments
The following environments are susceptible to an XSS attack:
- Web servers
- Application servers
- Web application environments
How to prevent
This section describes the top best practices designed to specifically protect your code:
- Sanitize data input in an HTTP request before reflecting it back, ensuring all data is validated, filtered or escaped before echoing anything back to the user, such as the values of query parameters during searches.
- Convert special characters such as
?,&,/,<,>and spaces to their respective HTML or URL encoded equivalents. - Give users the option to disable client-side scripts.
- Redirect invalid requests.
- Detect simultaneous logins, including those from two separate IP addresses, and invalidate those sessions.
- Use and enforce a Content Security Policy (source: Wikipedia) to disable any features that might be manipulated for an XSS attack.
- Read the documentation for any of the libraries referenced in your code to understand which elements allow for embedded HTML.
Remediation
Upgrade std/html/template to version 1.19.8, 1.20.3 or higher.
References
HTTP Request Smuggling
Detailed paths
Overview
std/net/http/internal is a Go standard library package std/net/http/internal
Affected versions of this package are vulnerable to HTTP Request Smuggling.
Go Vulnerability Report:
The net/http package improperly accepts a bare LF as a line terminator in chunked data chunk-size lines. This can permit request smuggling if a net/http server is used in conjunction with a server that incorrectly accepts a bare LF as part of a chunk-ext.
Remediation
Upgrade std/net/http/internal to version 1.23.8, 1.24.2 or higher.
References
Improper Check for Unusual or Exceptional Conditions
Detailed paths
Overview
std/net/netip is a Go standard library package std/net/netip
Affected versions of this package are vulnerable to Improper Check for Unusual or Exceptional Conditions.
Go Vulnerability Report:
The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected for IPv4-mapped IPv6 addresses, returning false for addresses which would return true in their traditional IPv4 forms.
Remediation
Upgrade std/net/netip to version 1.21.11, 1.22.4 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/archive/tar is a Go standard library package std/archive/tar
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
via the Reader.Read function. An attacker can cause excessive memory allocation and trigger resource exhaustion or application panics by supplying a specially crafted archive with oversized file headers.
Remediation
Upgrade std/archive/tar to version 1.18.7, 1.19.2 or higher.
References
Uncaught Exception
Detailed paths
Overview
std/archive/zip is a Go standard library package std/archive/zip
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
via the NewReader or OpenReader functions when processing an archive that specifies an unusually large number of files. An attacker can trigger a panic or cause an unrecoverable fatal error by supplying a crafted archive with manipulated file count metadata.
Remediation
Upgrade std/archive/zip to version 1.16.8, 1.17.1 or higher.
References
Uncaught Exception
Detailed paths
Overview
std/archive/zip is a Go standard library package std/archive/zip
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
via the Open function in the archive/zip package when processing zip files containing entries with names composed solely of slash characters or ".." path elements, or when an empty string is provided as an argument. An attacker can cause a panic and potentially disrupt application availability by crafting a malicious zip file with such entries.
Remediation
Upgrade std/archive/zip to version 1.16.10, 1.17.3 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/archive/zip is a Go standard library package std/archive/zip
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
archive/zip uses a super-linear file name indexing algorithm that is invoked the first time a file in an archive is opened. This can lead to a denial of service when consuming a maliciously constructed ZIP archive.
Remediation
Upgrade std/archive/zip to version 1.24.12, 1.25.6 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
Uncontrolled Recursion
Detailed paths
Overview
std/compress/gzip is a Go standard library package std/compress/gzip
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
via the Reader.Read function when processing an archive that contains a large number of concatenated zero-length compressed files. An attacker can cause a panic and exhaust the stack by supplying such a crafted archive.
Remediation
Upgrade std/compress/gzip to version 1.17.12, 1.18.4 or higher.
References
Uncaught Exception
Detailed paths
Overview
std/crypto/elliptic is a Go standard library package std/crypto/elliptic
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
via the P256().ScalarMult or P256().ScalarBaseMult functions when provided with a crafted scalar input longer than 32 bytes. An attacker can cause a panic and potentially disrupt service by supplying such an input. This is only exploitable if the architecture is not amd64, arm64, ppc64le, or s390x.
Remediation
Upgrade std/crypto/elliptic to version 1.17.9, 1.18.1 or higher.
References
Struts: Validator Without Form Field
Detailed paths
Overview
std/crypto/elliptic is a Go standard library package std/crypto/elliptic
Affected versions of this package are vulnerable to Struts: Validator Without Form Field.
Go Vulnerability Report:
via the IsOnCurve function. An attacker can trigger a panic or cause invalid cryptographic operations by supplying specially crafted big.Int values that are negative or overflow the expected field element range.
Remediation
Upgrade std/crypto/elliptic to version 1.16.14, 1.17.7 or higher.
References
Uncontrolled Recursion
Detailed paths
Overview
std/crypto/rand is a Go standard library package std/crypto/rand
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
in the rand.Read function on Windows when a buffer larger than 1 << 32 - 1 bytes is provided. An attacker can cause the process to hang indefinitely by supplying an excessively large buffer.
Remediation
Upgrade std/crypto/rand to version 1.17.11, 1.18.3 or higher.
References
Uncaught Exception
Detailed paths
Overview
std/crypto/tls is a Go standard library package std/crypto/tls
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
Large handshake records may cause panics in crypto/tls.Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses.This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client certificates (by setting Config.ClientAuth >= RequestClientCert).
Remediation
Upgrade std/crypto/tls to version 1.19.6, 1.20.1 or higher.
References
Timing Attack
Detailed paths
Overview
std/crypto/tls is a Go standard library package std/crypto/tls
Affected versions of this package are vulnerable to Timing Attack.
Go Vulnerability Report:
via the crypto/tls process. An attacker can recover session key bits by exploiting timing information leaked during the removal of PKCS#1 padding in RSA-based TLS key exchanges.
Remediation
Upgrade std/crypto/tls to version 1.20.0 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/crypto/tls is a Go standard library package std/crypto/tls
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service. This only affects TLS 1.3.
Remediation
Upgrade std/crypto/tls to version 1.25.9, 1.26.2 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
Uncaught Exception
Detailed paths
Overview
std/crypto/x509 is a Go standard library package std/crypto/x509
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
Validating certificate chains which contain DSA public keys can cause programs to panic, due to a interface cast that assumes they implement the Equal method.This affects programs which validate arbitrary certificate chains.
Remediation
Upgrade std/crypto/x509 to version 1.24.8, 1.25.2 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:
Due to the design of the name constraint checking algorithm, the processing time of some inputs scale non-linearly with respect to the size of the certificate.This affects programs which validate arbitrary certificate chains.
Remediation
Upgrade std/crypto/x509 to version 1.24.9, 1.25.3 or higher.
References
Uncaught Exception
Detailed paths
Overview
std/crypto/x509 is a Go standard library package std/crypto/x509
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
Verifying a certificate chain which contains a certificate with an unknown public key algorithm will cause Certificate.Verify to panic.This affects all crypto/tls clients, and servers that set Config.ClientAuth to VerifyClientCertIfGiven or RequireAndVerifyClientCert. The default behavior is for TLS servers to not verify client certificates.
Remediation
Upgrade std/crypto/x509 to version 1.21.8, 1.22.1 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:
Validating certificate chains which use policies is unexpectedly inefficient when certificates in the chain contain a very large number of policy mappings, possibly causing denial of service. This only affects validation of otherwise trusted certificate chains, issued by a root CA in the VerifyOptions.Roots CertPool, or in the system certificate pool.
Remediation
Upgrade std/crypto/x509 to version 1.25.9, 1.26.2 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
Race Condition
Detailed paths
Overview
std/database/sql is a Go standard library package std/database/sql
Affected versions of this package are vulnerable to Race Condition.
Go Vulnerability Report:
Cancelling a query (e.g. by cancelling the context passed to one of the query methods) during a call to the Scan method of the returned Rows can result in unexpected results if other queries are being made in parallel. This can result in a race condition that may overwrite the expected results with those of another query, causing the call to Scan to return either unexpected results from the other query or an error.
Remediation
Upgrade std/database/sql to version 1.23.12, 1.24.6 or higher.
References
Uncaught Exception
Detailed paths
Overview
std/debug/macho is a Go standard library package std/debug/macho
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
Calling File.ImportedSymbols on a loaded file which contains an invalid dynamic symbol table command can cause a panic, in particular if the encoded number of undefined symbols is larger than the number of symbols in the symbol table.
Remediation
Upgrade std/debug/macho to version 1.16.10, 1.17.3 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/gob is a Go standard library package std/encoding/gob
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion.
Remediation
Upgrade std/encoding/gob to version 1.17.12, 1.18.4 or higher.
References
Uncontrolled Recursion
Detailed paths
Overview
std/encoding/gob is a Go standard library package std/encoding/gob
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion. This is a follow-up to CVE-2022-30635.
Remediation
Upgrade std/encoding/gob to version 1.22.7, 1.23.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/encoding/pem is a Go standard library package std/encoding/pem
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
The processing time for parsing some invalid inputs scales non-linearly with respect to the size of the input.This affects programs which parse untrusted PEM inputs.
Remediation
Upgrade std/encoding/pem to version 1.24.8, 1.25.2 or higher.
References
Uncontrolled Recursion
Detailed paths
Overview
std/encoding/pem is a Go standard library package std/encoding/pem
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
Stack overflow via a large amount of PEM data via the Decode function. An attacker can cause a stack overflow and potentially crash the application by supplying a large amount of PEM data.
Remediation
Upgrade std/encoding/pem to version 1.17.9, 1.18.1 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:
Unmarshaling an XML document into a Go struct which has a nested field that uses the 'any' field tag can panic due to stack exhaustion.
Remediation
Upgrade std/encoding/xml to version 1.17.12, 1.18.4 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:
Calling Decoder.Skip when parsing a deeply nested XML document can cause a panic due to stack exhaustion.
Remediation
Upgrade std/encoding/xml to version 1.17.12, 1.18.4 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
Uncontrolled Recursion
Detailed paths
Overview
std/go/build/constraint is a Go standard library package std/go/build/constraint
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
Calling Parse on a "// +build" build tag line with deeply nested expressions can cause a panic due to stack exhaustion.
Remediation
Upgrade std/go/build/constraint to version 1.22.7, 1.23.1 or higher.
References
Infinite loop
Detailed paths
Overview
std/go/scanner is a Go standard library package std/go/scanner
Affected versions of this package are vulnerable to Infinite loop.
Go Vulnerability Report:
Calling any of the Parse functions on Go source code which contains //line directives with very large line numbers can cause an infinite loop due to integer overflow.
Remediation
Upgrade std/go/scanner to version 1.19.8, 1.20.3 or higher.
References
Relative Path Traversal
Detailed paths
Overview
std/internal/safefilepath is a Go standard library package std/internal/safefilepath
Affected versions of this package are vulnerable to Relative Path Traversal.
Go Vulnerability Report:
The filepath package does not recognize paths with a ??\ prefix as special.On Windows, a path beginning with ??\ is a Root Local Device path equivalent to a path beginning with \?. Paths with a ??\ prefix may be used to access arbitrary locations on the system. For example, the path ??\c:\x is equivalent to the more common path c:\x.Before fix, Clean could convert a rooted path such as \a..??\b into the root local device path ??\b. Clean will now convert this to .??\b.Similarly, Join(, ??, b) could convert a seemingly innocent sequence of path elements into the root local device path ??\b. Join will now convert this to .??\b.In addition, with fix, IsAbs now correctly reports paths beginning with ??\ as absolute, and VolumeName correctly reports the ??\ prefix as a volume name.UPDATE: Go 1.20.11 and Go 1.21.4 inadvertently changed the definition of the volume name in Windows paths starting with ?, resulting in filepath.Clean(?\c:) returning ?\c: rather than ?\c:\ (among other effects). The previous behavior has been restored.
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/internal/safefilepath to version 1.20.11, 1.21.4 or higher.
References
Time-of-check Time-of-use (TOCTOU) Race Condition
Detailed paths
Overview
std/internal/syscall/unix is a Go standard library package std/internal/syscall/unix
Affected versions of this package are vulnerable to Time-of-check Time-of-use (TOCTOU) Race Condition.
Go Vulnerability Report:
On Linux, if the target of Root.Chmod is replaced with a symlink while the chmod operation is in progress, Chmod can operate on the target of the symlink, even when the target lies outside the root. The Linux fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag, which Root.Chmod uses to avoid symlink traversal. Root.Chmod checks its target before acting and returns an error if the target is a symlink lying outside the root, so the impact is limited to cases where the target is replaced with a symlink between the check and operation.
Remediation
Upgrade std/internal/syscall/unix to version 1.25.9, 1.26.2 or higher.
References
Uncontrolled Recursion
Detailed paths
Overview
std/io/fs is a Go standard library package std/io/fs
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
Calling Glob on a path which contains a large number of path separators can cause a panic due to stack exhaustion.
Remediation
Upgrade std/io/fs to version 1.17.12, 1.18.4 or higher.
References
Uncaught Exception
Detailed paths
Overview
std/math/big is a Go standard library package std/math/big
Affected versions of this package are vulnerable to Uncaught Exception.
Go Vulnerability Report:
Decoding big.Float and big.Rat types can panic if the encoded message is too short, potentially allowing a denial of service.
Remediation
Upgrade std/math/big to version 1.17.13, 1.18.5 or higher.
References
Integer Overflow or Wraparound
Detailed paths
Overview
std/math/big is a Go standard library package std/math/big
Affected versions of this package are vulnerable to Integer Overflow or Wraparound.
Go Vulnerability Report:
Rat.SetString had an overflow issue that can lead to uncontrolled memory consumption.
Remediation
Upgrade std/math/big to version 1.16.14, 1.17.7 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
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/mime/multipart is a Go standard library package std/mime/multipart
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
A denial of service is possible from excessive resource consumption in net/http and mime/multipart.Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely unlimited amounts of memory and disk files. This also affects form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue.ReadForm takes a maxMemory parameter, and is documented as storing "up to maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files.With fix, ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous.In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type's documentation states, "If stored on disk, the File's underlying concrete type will be an *os.File.". This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct.Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader.
Remediation
Upgrade std/mime/multipart to version 1.19.6, 1.20.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/mime/multipart is a Go standard library package std/mime/multipart
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes:
mime/multipart.Reader.ReadFormlimits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended.- Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts.
- ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector.
The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use
mime/multipart.Reader.ReadForm, as well as form parsing in thenet/httppackage with the Request methodsFormFile,FormValue,ParseMultipartForm, andPostFormValue.Withfix,ReadFormnow does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations.In addition, the fixedmime/multipart.Readerimposes the following limits on the size of parsed forms: - Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable
GODEBUG=multipartmaxparts=. - Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable
GODEBUG=multipartmaxheaders=.
Remediation
Upgrade std/mime/multipart to version 1.19.8, 1.20.3 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
Directory Traversal
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to Directory Traversal.
Go Vulnerability Report:
On Windows, restricted files can be accessed via os.DirFS and http.Dir.The os.DirFS function and http.Dir type provide access to a tree of files rooted at a given directory. These functions permit access to Windows device files under that root. For example, os.DirFS("C:/tmp").Open("COM1") opens the COM1 device. Both os.DirFS and http.Dir only provide read-only filesystem access. In addition, on Windows, an os.DirFS for the directory (the root of the current drive) can permit a maliciously crafted path to escape from the drive and access any path on the system.With fix applied, the behavior of os.DirFS("") has changed. Previously, an empty root was treated equivalently to "/", so os.DirFS("").Open("tmp") would open the path "/tmp". This now returns an error.
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/net/http to version 1.18.9, 1.19.4 or higher.
References
Insertion of Sensitive Information Into Sent Data
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to Insertion of Sensitive Information Into Sent Data.
Go Vulnerability Report:
Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.
Remediation
Upgrade std/net/http to version 1.23.10, 1.24.4 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an "Expect: 100-continue" header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail.An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending "Expect: 100-continue" requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail.
Remediation
Upgrade std/net/http to version 1.21.12, 1.22.5 or higher.
References
HTTP Response Splitting
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to HTTP Response Splitting.
Go Vulnerability Report:
The HTTP/1 client does not fully validate the contents of the Host header. A maliciously crafted Host header can inject additional headers or entire requests.With fix, the HTTP/1 client now refuses to send requests containing an invalid Request.Host or Request.URL.Host value.
Remediation
Upgrade std/net/http to version 1.19.11, 1.20.6 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
An attacker can cause unbounded memory growth in servers accepting HTTP/2 requests.
Remediation
Upgrade std/net/http to version 1.16.12, 1.17.5 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames.Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed.This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send.The fix sets a limit on the amount of excess header frames we will process before closing a connection.
Remediation
Upgrade std/net/http to version 1.21.9, 1.22.2 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing.With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection.This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2.The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.
Remediation
Upgrade std/net/http to version 1.20.10, 1.21.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:
HTTP/2 server connections can hang forever waiting for a clean shutdown that was preempted by a fatal error. This condition can be exploited by a malicious client to cause a denial of service.
Remediation
Upgrade std/net/http to version 1.18.6, 1.19.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/http is a Go standard library package std/net/http
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
A maliciously crafted HTTP/2 stream could cause excessive CPU consumption in the HPACK decoder, sufficient to cause a denial of service from a small number of small requests.
Remediation
Upgrade std/net/http to version 1.19.6, 1.20.1 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
HTTP Request Smuggling
Detailed paths
Overview
std/net/http/httputil is a Go standard library package std/net/http/httputil
Affected versions of this package are vulnerable to HTTP Request Smuggling.
Go Vulnerability Report:
Requests forwarded by ReverseProxy include the raw query parameters from the inbound request, including unparsable parameters rejected by net/http. This could permit query parameter smuggling when a Go proxy forwards a parameter with an unparsable value.After fix, ReverseProxy sanitizes the query parameters in the forwarded query when the outbound request's Form field is set after the ReverseProxy. Director function returns, indicating that the proxy has parsed the query parameters. Proxies which do not parse query parameters continue to forward the original query parameters unchanged.
Remediation
Upgrade std/net/http/httputil to version 1.18.7, 1.19.2 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:
The ParseAddress function constructs domain-literal address components through repeated string concatenation. When parsing large domain-literal components, this can cause excessive CPU consumption.
Remediation
Upgrade std/net/mail to version 1.24.8, 1.25.2 or higher.
References
Improper Neutralization
Detailed paths
Overview
std/net/mail is a Go standard library package std/net/mail
Affected versions of this package are vulnerable to Improper Neutralization.
Go Vulnerability Report:
The ParseAddressList function incorrectly handles comments (text within parentheses) within display names. Since this is a misalignment with conforming address parsers, it can result in different trust decisions being made by programs using different parsers.
Remediation
Upgrade std/net/mail to version 1.21.8, 1.22.1 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
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/textproto is a Go standard library package std/net/textproto
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
When parsing a multipart form (either explicitly with Request.ParseMultipartForm or implicitly with Request.FormValue, Request.PostFormValue, or Request.FormFile), limits on the total size of the parsed form were not applied to the memory consumed while reading a single form line. This permits a maliciously crafted input containing very long lines to cause allocation of arbitrarily large amounts of memory, potentially leading to memory exhaustion. With fix, the ParseMultipartForm function now correctly limits the maximum size of form lines.
Remediation
Upgrade std/net/textproto to version 1.21.8, 1.22.1 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/textproto is a Go standard library package std/net/textproto
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
HTTP and MIME header parsing can allocate large amounts of memory, even when parsing small inputs, potentially leading to a denial of service. Certain unusual patterns of input data can cause the common function used to parse HTTP and MIME headers to allocate substantially more memory than required to hold the parsed headers. An attacker can exploit this behavior to cause an HTTP server to allocate large amounts of memory from a small request, potentially leading to memory exhaustion and a denial of service.With fix, header parsing now correctly allocates only the memory required to hold parsed headers.
Remediation
Upgrade std/net/textproto to version 1.19.8, 1.20.3 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/textproto is a Go standard library package std/net/textproto
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes:
mime/multipart.Reader.ReadFormlimits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended.- Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts.
- ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector.
The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use
mime/multipart.Reader.ReadForm, as well as form parsing in thenet/httppackage with the Request methodsFormFile,FormValue,ParseMultipartForm, andPostFormValue.Withfix,ReadFormnow does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations.In addition, the fixedmime/multipart.Readerimposes the following limits on the size of parsed forms: - Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable
GODEBUG=multipartmaxparts=. - Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable
GODEBUG=multipartmaxheaders=.
Remediation
Upgrade std/net/textproto to version 1.19.8, 1.20.3 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/net/url is a Go standard library package std/net/url
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
The net/url package does not set a limit on the number of query parameters in a query. While the maximum size of query parameters in URLs is generally limited by the maximum request header size, the net/http.Request.ParseForm method can parse large URL-encoded forms. Parsing a large form containing many unique query parameters can cause excessive memory consumption.
Remediation
Upgrade std/net/url to version 1.24.12, 1.25.6 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
Directory Traversal
Detailed paths
Overview
std/os is a Go standard library package std/os
Affected versions of this package are vulnerable to Directory Traversal.
Go Vulnerability Report:
On Windows, restricted files can be accessed via os.DirFS and http.Dir.The os.DirFS function and http.Dir type provide access to a tree of files rooted at a given directory. These functions permit access to Windows device files under that root. For example, os.DirFS("C:/tmp").Open("COM1") opens the COM1 device. Both os.DirFS and http.Dir only provide read-only filesystem access. In addition, on Windows, an os.DirFS for the directory (the root of the current drive) can permit a maliciously crafted path to escape from the drive and access any path on the system.With fix applied, the behavior of os.DirFS("") has changed. Previously, an empty root was treated equivalently to "/", so os.DirFS("").Open("tmp") would open the path "/tmp". This now returns an error.
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/os to version 1.18.9, 1.19.4 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
Untrusted Search Path
Detailed paths
Overview
std/os/exec is a Go standard library package std/os/exec
Affected versions of this package are vulnerable to Untrusted Search Path.
Go Vulnerability Report:
On Windows, executing Cmd.Run, Cmd.Start, Cmd.Output, or Cmd.CombinedOutput when Cmd.Path is unset will unintentionally trigger execution of any binaries in the working directory named either ..com or ..exe.
Remediation
Upgrade std/os/exec to version 1.17.11, 1.18.3 or higher.
References
Directory Traversal
Detailed paths
Overview
std/path/filepath is a Go standard library package std/path/filepath
Affected versions of this package are vulnerable to Directory Traversal.
Go Vulnerability Report:
On Windows, the filepath.Clean function can convert certain invalid paths to valid, absolute paths, potentially allowing a directory traversal attack. For example, Clean(".\c:") returns "c:".
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/path/filepath to version 1.17.11, 1.18.3 or higher.
References
Uncontrolled Recursion
Detailed paths
Overview
std/path/filepath is a Go standard library package std/path/filepath
Affected versions of this package are vulnerable to Uncontrolled Recursion.
Go Vulnerability Report:
Calling Glob on a path which contains a large number of path separators can cause a panic due to stack exhaustion.
Remediation
Upgrade std/path/filepath to version 1.17.12, 1.18.4 or higher.
References
Directory Traversal
Detailed paths
Overview
std/path/filepath is a Go standard library package std/path/filepath
Affected versions of this package are vulnerable to Directory Traversal.
Go Vulnerability Report:
A path traversal vulnerability exists in filepath.Clean on Windows.On Windows, the filepath.Clean function could transform an invalid path such as "a/../c:/b" into the valid path "c:\b". This transformation of a relative (if invalid) path into an absolute path could enable a directory traversal attack.After fix, the filepath.Clean function transforms this path into the relative (but still invalid) path ".\c:\b".
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/path/filepath to version 1.19.6, 1.20.1 or higher.
References
Relative Path Traversal
Detailed paths
Overview
std/path/filepath is a Go standard library package std/path/filepath
Affected versions of this package are vulnerable to Relative Path Traversal.
Go Vulnerability Report:
The filepath package does not recognize paths with a ??\ prefix as special.On Windows, a path beginning with ??\ is a Root Local Device path equivalent to a path beginning with \?. Paths with a ??\ prefix may be used to access arbitrary locations on the system. For example, the path ??\c:\x is equivalent to the more common path c:\x.Before fix, Clean could convert a rooted path such as \a..??\b into the root local device path ??\b. Clean will now convert this to .??\b.Similarly, Join(, ??, b) could convert a seemingly innocent sequence of path elements into the root local device path ??\b. Join will now convert this to .??\b.In addition, with fix, IsAbs now correctly reports paths beginning with ??\ as absolute, and VolumeName correctly reports the ??\ prefix as a volume name.UPDATE: Go 1.20.11 and Go 1.21.4 inadvertently changed the definition of the volume name in Windows paths starting with ?, resulting in filepath.Clean(?\c:) returning ?\c: rather than ?\c:\ (among other effects). The previous behavior has been restored.
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/path/filepath to version 1.20.12, 1.21.5 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/regexp is a Go standard library package std/regexp
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
On 64-bit platforms, an extremely deeply nested expression can cause regexp.Compile to cause goroutine stack exhaustion, forcing the program to exit. Note this applies to very large expressions, on the order of 2MB.
Remediation
Upgrade std/regexp to version 1.16.15, 1.17.8 or higher.
References
Allocation of Resources Without Limits or Throttling
Detailed paths
Overview
std/regexp/syntax is a Go standard library package std/regexp/syntax
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling.
Go Vulnerability Report:
Programs which compile regular expressions from untrusted sources may be vulnerable to memory exhaustion or denial of service.The parsed regexp representation is linear in the size of the input, but in some cases the constant factor can be as high as 40,000, making relatively small regexps consume much larger amounts of memory.After fix, each regexp being parsed is limited to a 256 MB memory footprint. Regular expressions whose representation would use more space than that are rejected. Normal use of regular expressions is unaffected.
Remediation
Upgrade std/regexp/syntax to version 1.18.7, 1.19.2 or higher.
References
Incorrect Privilege Assignment
Detailed paths
Overview
std/runtime is a Go standard library package std/runtime
Affected versions of this package are vulnerable to Incorrect Privilege Assignment.
Go Vulnerability Report:
On Unix platforms, the Go runtime does not behave differently when a binary is run with the setuid/setgid bits. This can be dangerous in certain cases, such as when dumping memory state, or assuming the status of standard i/o file descriptors.If a setuid/setgid binary is executed with standard I/O file descriptors closed, opening any files can result in unexpected content being read or written with elevated privileges. Similarly, if a setuid/setgid program is terminated, either via panic or signal, it may leak the contents of its registers.
Remediation
Upgrade std/runtime to version 1.19.10, 1.20.5 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 rsync package and not the rsync package as distributed by Ubuntu.
See How to fix? for Ubuntu:20.04 relevant fixed versions and status.
Rsync versions before 3.4.3 contain a time-of-check to time-of-use (TOCTOU) race condition in daemon file handling that allows attackers to redirect file writes outside intended directories by replacing parent directory components with symbolic links. Attackers with write access to a module path can exploit this race condition to create or overwrite arbitrary files, potentially modifying sensitive system files and achieving privilege escalation when the daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false.
Remediation
Upgrade Ubuntu:20.04 rsync to version 3.1.3-8ubuntu0.9+esm1 or higher.
References
- http://people.ubuntu.com/~ubuntu-security/cve/CVE-2026-29518
- https://github.com/RsyncProject/rsync/pull/895/changes/8471fdd1561049ef5f58df44a1811a50bd9a531d
- https://github.com/RsyncProject/rsync/releases/tag/v3.4.3
- https://www.vulncheck.com/advisories/rsync-toctou-race-condition-allows-symlink-based-arbitrary-file-write
- https://michael.stapelberg.ch/posts/2026-05-24-minimal-memory-safe-go-rsync-vulns/
- https://access.redhat.com/errata/RHSA-2026:26332
- https://access.redhat.com/errata/RHSA-2026:26408
- https://access.redhat.com/errata/RHSA-2026:26410
- https://access.redhat.com/errata/RHSA-2026:29197
- https://access.redhat.com/security/cve/CVE-2026-29518
- https://bugzilla.redhat.com/show_bug.cgi?id=2469055
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-29518.json
- https://access.redhat.com/errata/RHSA-2026:54769
Out-of-bounds Read
Detailed paths
NVD Description
Note: Versions mentioned in the description apply only to the upstream rsync package and not the rsync package as distributed by Ubuntu.
See How to fix? for Ubuntu:20.04 relevant fixed versions and status.
Rsync version 3.4.2 and prior contain an integer overflow vulnerability in the compressed-token decoder where a 32-bit signed counter is not checked for overflow, allowing a malicious sender to trigger an overflow that causes the receiver process to read and return data from outside the intended buffer bounds. Attackers can exploit this vulnerability to disclose process memory contents including environment variables, passwords, heap and stack data, and library memory pointers, significantly reducing ASLR effectiveness and facilitating further exploitation.
Remediation
Upgrade Ubuntu:20.04 rsync to version 3.1.3-8ubuntu0.9+esm1 or higher.
References
- http://people.ubuntu.com/~ubuntu-security/cve/CVE-2026-43618
- https://github.com/RsyncProject/rsync/releases/tag/v3.4.3
- https://github.com/RsyncProject/rsync/security/advisories/GHSA-g37v-g3gj-pmwq
- https://www.vulncheck.com/advisories/rsync-integer-overflow-information-disclosure
- https://access.redhat.com/errata/RHSA-2026:26332
- https://access.redhat.com/errata/RHSA-2026:26408
- https://access.redhat.com/errata/RHSA-2026:26410
- https://access.redhat.com/errata/RHSA-2026:29197
- https://access.redhat.com/security/cve/CVE-2026-43618
- https://bugzilla.redhat.com/show_bug.cgi?id=2469054
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43618.json
CVE-2026-45447
Detailed paths
NVD Description
Note: Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Ubuntu.
See How to fix? for Ubuntu:20.04 relevant fixed versions and status.
Issue summary: A specially crafted PKCS#7 or S/MIME signed message could trigger a use-after-free during PKCS#7 signature verification.
Impact summary: A use-after-free may result in process crashes, heap corruption, or potentially remote code execution.
When processing a PKCS#7 or S/MIME signed message, if the SignedData digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may incorrectly free a caller-owned BIO during PKCS7_verify(). A subsequent use of the BIO by the calling application results in a use-after-free condition.
In the common case this occurs when the application later calls BIO_free() on the BIO originally passed to PKCS7_verify(). Depending on allocator behavior and application-specific BIO usage patterns, this may result in a crash or other memory corruption. In some application contexts this may potentially be exploitable for remote code execution.
Applications that process PKCS#7 or S/MIME signed messages using OpenSSL PKCS#7 APIs may be affected. Applications using the CMS APIs for this processing are not affected.
The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.
Remediation
Upgrade Ubuntu:20.04 openssl to version 1.1.1f-1ubuntu2.24+esm4 or higher.
References
- http://people.ubuntu.com/~ubuntu-security/cve/CVE-2026-45447
- https://github.com/openssl/security/commit/3aad5eb7af4de4ee0633c30a8541a54d9bbde63c
- https://github.com/openssl/security/commit/7d4a980c62258c5910cc883936e0c8dbab4d75a8
- https://github.com/openssl/security/commit/9dfd688ad2290fc5075cacbc9bf0c9a93eefed54
- https://github.com/openssl/security/commit/a541ae8bfe849a30cc885e8780715c0f488e496c
- https://github.com/openssl/security/commit/c505d7559da5d5f9f2c3913c6883a5562ce7273e
- https://github.com/openssl/openssl/commit/3aad5eb7af4de4ee0633c30a8541a54d9bbde63c
- https://github.com/openssl/openssl/commit/7d4a980c62258c5910cc883936e0c8dbab4d75a8
- https://github.com/openssl/openssl/commit/9dfd688ad2290fc5075cacbc9bf0c9a93eefed54
- https://github.com/openssl/openssl/commit/a541ae8bfe849a30cc885e8780715c0f488e496c
- https://github.com/openssl/openssl/commit/c505d7559da5d5f9f2c3913c6883a5562ce7273e
- https://openssl-library.org/news/secadv/20260609.txt
- https://access.redhat.com/errata/RHSA-2026:25237
- https://access.redhat.com/errata/RHSA-2026:25239
- https://access.redhat.com/errata/RHSA-2026:26275
- https://access.redhat.com/errata/RHSA-2026:26319
- https://access.redhat.com/errata/RHSA-2026:29197
- https://access.redhat.com/errata/RHSA-2026:34102
- https://access.redhat.com/errata/RHSA-2026:35869
- https://access.redhat.com/errata/RHSA-2026:36215
- https://access.redhat.com/errata/RHSA-2026:36217
- https://access.redhat.com/errata/RHSA-2026:39009
- https://access.redhat.com/errata/RHSA-2026:39012
- https://access.redhat.com/errata/RHSA-2026:39981
- https://access.redhat.com/security/cve/CVE-2026-45447
- https://bugzilla.redhat.com/show_bug.cgi?id=2481898
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-45447.json
- https://access.redhat.com/errata/RHSA-2026:44438
- https://access.redhat.com/errata/RHSA-2026:47735
- https://access.redhat.com/errata/RHSA-2026:47737
- https://access.redhat.com/errata/RHSA-2026:58563
- https://access.redhat.com/errata/RHSA-2026:58981
- https://access.redhat.com/errata/RHSA-2026:59831
- https://access.redhat.com/errata/RHSA-2026:66524
CVE-2026-84782
Detailed paths
NVD Description
Note: Versions mentioned in the description apply only to the upstream openssl package and not the openssl package as distributed by Ubuntu.
See How to fix? for Ubuntu:20.04 relevant fixed versions and status.
Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly.
Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region.
CWE: CWE-125: Out-of-bounds Read
Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue.
The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer.
Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build.
The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead.
FIPS impact: no The affected code is outside the FIPS module boundary.
Remediation
Upgrade Ubuntu:20.04 openssl to version 1.1.1f-1ubuntu2.24+esm6 or higher.
References
- http://people.ubuntu.com/~ubuntu-security/cve/CVE-2026-84782
- https://github.com/openssl/openssl/commit/906cf0ef1c85ca40ce69163e9086d6d3fe292943
- https://github.com/openssl/openssl/commit/9f6b34422af7eb5dac61322e33dac1ae989fa628
- https://github.com/openssl/openssl/commit/a383dafdd754eb5b22bf45e37e1bff9d07277a58
- https://github.com/openssl/openssl/commit/d951e02ede8f6a6ff8150546db44b34f0518192c
- https://openssl-library.org/news/secadv/20260929.txt
Out-of-bounds Write
Detailed paths
NVD Description
Note: Versions mentioned in the description apply only to the upstream gnupg2 package and not the gnupg2 package as distributed by Ubuntu.
See How to fix? for Ubuntu:20.04 relevant fixed versions and status.
In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)
Remediation
Upgrade Ubuntu:20.04 gnupg2 to version 2.2.19-3ubuntu2.5+esm1 or higher.
References
- http://people.ubuntu.com/~ubuntu-security/cve/CVE-2025-68973
- https://github.com/gpg/gnupg/blob/ff30683418695f5d2cc9e6cf8c9418e09378ebe4/g10/armor.c#L1305-L1306
- https://github.com/gpg/gnupg/commit/115d138ba599328005c5321c0ef9f00355838ca9
- https://github.com/gpg/gnupg/compare/gnupg-2.2.50...gnupg-2.2.51
- https://media.ccc.de/v/39c3-to-sign-or-not-to-sign-practical-vulnerabilities-i
- https://news.ycombinator.com/item?id=46403200
- https://www.openwall.com/lists/oss-security/2025/12/28/5
- http://www.openwall.com/lists/oss-security/2025/12/29/11
- https://lists.debian.org/debian-lts-announce/2026/01/msg00008.html
- https://gpg.fail/memcpy
Race Condition Enabling Link Following
Detailed paths
Overview
Affected versions of this package are vulnerable to Race Condition Enabling Link Following due to insufficient checks when bind-mounting /dev/pts/$n to /dev/console inside the container. An attacker can gain unauthorized write access to sensitive files within the container environment by manipulating the timing of mount operations and providing a malicious configuration, potentially leading to denial of service or container escape.
Note:
This is only exploitable if the attacker can supply a crafted container configuration and execute processes with sufficient privileges inside the container.
Workaround
This vulnerability can be mitigated by:
Using containers with user namespaces enabled.
Configuring containers to not permit processes to run with root privileges.
Applying SELinux policies that restrict access to
/dev/console.
Remediation
Upgrade github.com/opencontainers/runc/libcontainer/system to version 1.2.8, 1.3.3, 1.4.0-rc.3 or higher.
References
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
Race Condition Enabling Link Following
Detailed paths
Overview
Affected versions of this package are vulnerable to Race Condition Enabling Link Following in the handling of procfs file writes. An attacker can cause arbitrary writes to sensitive files or trigger a denial of service by redirecting write operations through race conditions and manipulating shared mounts or symbolic links. This can result in bypassing security mechanisms, escalating privileges, or crashing the host system by targeting files such as /proc/sysrq-trigger or altering kernel parameters.
Workaround
This vulnerability can be mitigated by:
Do not run untrusted container images from unknown or unverified sources.
Using rootless containers.
Remediation
Upgrade github.com/opencontainers/runc/libcontainer/system to version 1.2.8, 1.3.3, 1.4.0-rc.3 or higher.
References
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub Commit
- GitHub PR
- PoC in GitHub