p PatchFirst

PatchFirst · Vulnérabilités récentes

Vulnérabilités de golang-1.14 · Page n° 6

Vulnérabilités publiées pour golang-1.14 au cours des 30 derniers jours : 17. Présentes dans le catalogue KEV : 0.

Filtrer les vulnérabilités
Effacer les filtres

Vulnérabilités : 136

  1. CVE-2023-24538

    Critique · CVSS 9.8EPSS 2,28%Aucun correctif publié

    Backticks not treated as string delimiters in html/template

    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

    Publication Mise à jour
  2. CVE-2023-24534

    Élevée · CVSS 7.5EPSS 1,89%Aucun correctif publié

    Excessive memory allocation in net/http and net/textproto

    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.

    Publication Mise à jour
  3. CVE-2023-24536

    Élevée · CVSS 7.5EPSS 1,48%Aucun correctif publié

    Excessive resource consumption in net/http, net/textproto and mime/multipart

    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: 1. mime/multipart.Reader.ReadForm limits 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. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combi

    Publication Mise à jour
  4. CVE-2023-24532

    Moyenne · CVSS 5.3EPSS 0,82%Aucun correctif publié

    Incorrect calculation on P256 curves in crypto/internal/nistec

    The ScalarMult and ScalarBaseMult methods of the P256 Curve may return an incorrect result if called with some specific unreduced scalars (a scalar larger than the order of the curve). This does not impact usages of crypto/ecdsa or crypto/ecdh.

    Publication Mise à jour
  5. CVE-2022-41724

    Élevée · CVSS 7.5EPSS 1,11%Aucun correctif publié

    Panic on large handshake records in crypto/tls

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

    Publication Mise à jour
  6. CVE-2022-41725

    Élevée · CVSS 7.5EPSS 1,24%Aucun correctif publié

    Excessive resource consumption in mime/multipart

    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

    Publication Mise à jour
  7. CVE-2022-41717

    Moyenne · CVSS 5.3EPSS 6,08%Aucun correctif publié

    Excessive memory growth in net/http and golang.org/x/net/http2

    An attacker can cause excessive memory growth in a Go server accepting HTTP/2 requests. HTTP/2 server connections contain a cache of HTTP header keys sent by the client. While the total number of entries in this cache is capped, an attacker sending very large keys can cause the server to allocate approximately 64 MiB per open connection.

    Publication Mise à jour
  8. CVE-2022-41716

    Moyenne · CVSS 6.3EPSS 0,85%Aucun correctif publié

    Unsanitized NUL in environment variables on Windows in syscall and os/exec

    Due to unsanitized NUL values, attackers may be able to maliciously set environment variables on Windows. In syscall.StartProcess and os/exec.Cmd, invalid environment variable values containing NUL values are not properly checked for. A malicious environment variable value can exploit this behavior to set a value for a different environment variable. For example, the environment variable string "A=B\x00C=D" sets the variables "A=B" and "C=D".

    Publication Mise à jour
  9. CVE-2022-41715

    Élevée · CVSS 7.5EPSS 1,73%Aucun correctif publié

    Memory exhaustion when compiling regular expressions in regexp/syntax

    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.

    Publication Mise à jour
  10. CVE-2022-2880

    Élevée · CVSS 7.5EPSS 1,41%Aucun correctif publié

    Incorrect sanitization of forwarded query parameters in net/http/httputil

    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.

    Publication Mise à jour
  11. CVE-2022-2879

    Élevée · CVSS 7.5EPSS 2,01%Aucun correctif publié

    Unbounded memory consumption when reading headers in archive/tar

    Reader.Read does not set a limit on the maximum size of file headers. A maliciously crafted archive could cause Read to allocate unbounded amounts of memory, potentially causing resource exhaustion or panics. After fix, Reader.Read limits the maximum size of header blocks to 1 MiB.

    Publication Mise à jour

Vérifiez votre serveur

Comparez votre pile et les versions installées aux bases de vulnérabilités actuelles.

Vérifiez votre serveur →