https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 15:29:03 +0000 https://cve.radiocsirt.org/vuln/alsa-2023:6346 <p><strong>Affected:</strong> AlmaLinux:9: toolbox, AlmaLinux:9: toolbox-tests</p> <p>Toolbox is a tool for Linux operating systems, which allows the use of containerized command line environments. It is built on top of Podman and other standard container technologies from OCI.</p> <p>Security Fix(es):</p> <p>* go-yaml: Improve heuristics preventing CPU/memory abuse by parsing malicious or large YAML documents (CVE-2022-3064) * golang: html/template: improper handling of JavaScript whitespace (CVE-2023-24540) * net/http, golang.org/x/net/http2: avoid quadratic complexity in HPACK decoding (CVE-2022-41723) * golang: net/http, mime/multipart: denial of service from excessive resource consumption (CVE-2022-41725) * golang: net/http, net/textproto: denial of service from excessive memory allocation (CVE-2023-24534) * golang: net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption (CVE-2023-24536) * golang: html/template: backticks not treated as string delimiters (CVE-2023-24538) * golang: html/template: improper sanitization of CSS values (CVE-2023-24539) * golang: html/template: improper handling of empty HTML attributes (CVE-2023-29400) * golang: net/http: insufficient sanitization of Host header (CVE-2023-29406)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> <p>Additional Changes:</p> <p>For detailed information on changes in this release, see the AlmaLinux Release Notes linked from the References se…</p> <p><strong>Affected:</strong> AlmaLinux:9: toolbox, AlmaLinux:9: toolbox-tests</p> <p>Toolbox is a tool for Linux operating systems, which allows the use of containerized command line environments. It is built on top of Podman and other standard container technologies from OCI.</p> <p>Security Fix(es):</p> <p>* go-yaml: Improve heuristics preventing CPU/memory abuse by parsing malicious or large YAML documents (CVE-2022-3064) * golang: html/template: improper handling of JavaScript whitespace (CVE-2023-24540) * net/http, golang.org/x/net/http2: avoid quadratic complexity in HPACK decoding (CVE-2022-41723) * golang: net/http, mime/multipart: denial of service from excessive resource consumption (CVE-2022-41725) * golang: net/http, net/textproto: denial of service from excessive memory allocation (CVE-2023-24534) * golang: net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption (CVE-2023-24536) * golang: html/template: backticks not treated as string delimiters (CVE-2023-24538) * golang: html/template: improper sanitization of CSS values (CVE-2023-24539) * golang: html/template: improper handling of empty HTML attributes (CVE-2023-29400) * golang: net/http: insufficient sanitization of Host header (CVE-2023-29406)</p> <p>For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</p> <p>Additional Changes:</p> <p>For detailed information on changes in this release, see the AlmaLinux Release Notes linked from the References se…</p> https://cve.radiocsirt.org/vuln/alsa-2023:6346 https://cve.radiocsirt.org/vuln/bdu:2024-03153 bdu:2024-03153 https://cve.radiocsirt.org/vuln/bdu:2024-03153 https://cve.radiocsirt.org/vuln/bell-cve-2023-24536 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Withdrawn by the publisher.</strong></p> https://cve.radiocsirt.org/vuln/bell-cve-2023-24536 https://cve.radiocsirt.org/vuln/bit-golang-2023-24536 <p><strong>Affected:</strong> Bitnami: golang</p> <p>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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no mor…</p> <p><strong>Affected:</strong> Bitnami: golang</p> <p>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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no mor…</p> https://cve.radiocsirt.org/vuln/bit-golang-2023-24536 https://cve.radiocsirt.org/vuln/certfr-2023-avi-0484 certfr-2023-avi-0484 https://cve.radiocsirt.org/vuln/certfr-2023-avi-0484 https://cve.radiocsirt.org/vuln/euvd-2026-216303 EUVD-2026-216303 https://cve.radiocsirt.org/vuln/euvd-2026-216303 https://cve.radiocsirt.org/vuln/fkie_cve-2023-24536 <p>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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no mor…</p> <p>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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no mor…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2023-24536 https://cve.radiocsirt.org/vuln/ghsa-9f7g-gqwh-jpf5 <p>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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no mor…</p> <p>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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no mor…</p> https://cve.radiocsirt.org/vuln/ghsa-9f7g-gqwh-jpf5 https://cve.radiocsirt.org/vuln/gsd-2023-24536 gsd-2023-24536 https://cve.radiocsirt.org/vuln/gsd-2023-24536 https://cve.radiocsirt.org/vuln/msrc_cve-2023-24536 msrc_CVE-2023-24536 https://cve.radiocsirt.org/vuln/msrc_cve-2023-24536 https://cve.radiocsirt.org/vuln/oesa-2023-1237 <p><strong>Affected:</strong> openEuler:20.03-LTS-SP1: golang, openEuler:20.03-LTS-SP3: golang, openEuler:22.03-LTS: golang, openEuler:22.03-LTS-SP1: golang</p> <p>The Go Programming Language. Security Fix(es): 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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts pa…</p> <p><strong>Affected:</strong> openEuler:20.03-LTS-SP1: golang, openEuler:20.03-LTS-SP3: golang, openEuler:22.03-LTS: golang, openEuler:22.03-LTS-SP1: golang</p> <p>The Go Programming Language. Security Fix(es): 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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts pa…</p> https://cve.radiocsirt.org/vuln/oesa-2023-1237 https://cve.radiocsirt.org/vuln/opensuse-su-2024:12841-1 <p>go1.20-1.20.3-1.1 on GA media</p> <p>go1.20-1.20.3-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2024:12841-1 https://cve.radiocsirt.org/vuln/rhba-2023:4275 <p>golang: net/http: handle server errors after sending GOAWAY golang: golang.org/x/text/language: ParseAcceptLanguage takes a long time to parse complex tags golang: net/url: JoinPath does not strip relative path components in all circumstances golang: net/http: excessive memory growth in a Go server accepting HTTP/2 requests golang.org/x/net/http2: avoid quadratic complexity in HPACK decoding golang: crypto/tls: large handshake records may cause panics golang: net/http, mime/multipart: denial of service from excessive resource consumption golang: net/http, net/textproto: denial of service from excessive memory allocation golang: net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption golang: go/parser: Infinite loop in parsing golang: html/template: backticks not treated as string delimiters golang: html/template: improper sanitization of CSS values golang: html/template: improper handling of JavaScript whitespace golang: html/template: improper handling of empty HTML attributes</p> <p>golang: net/http: handle server errors after sending GOAWAY golang: golang.org/x/text/language: ParseAcceptLanguage takes a long time to parse complex tags golang: net/url: JoinPath does not strip relative path components in all circumstances golang: net/http: excessive memory growth in a Go server accepting HTTP/2 requests golang.org/x/net/http2: avoid quadratic complexity in HPACK decoding golang: crypto/tls: large handshake records may cause panics golang: net/http, mime/multipart: denial of service from excessive resource consumption golang: net/http, net/textproto: denial of service from excessive memory allocation golang: net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption golang: go/parser: Infinite loop in parsing golang: html/template: backticks not treated as string delimiters golang: html/template: improper sanitization of CSS values golang: html/template: improper handling of JavaScript whitespace golang: html/template: improper handling of empty HTML attributes</p> https://cve.radiocsirt.org/vuln/rhba-2023:4275 https://cve.radiocsirt.org/vuln/suse-su-2023:2105-2 <p>Security update for go1.20</p> <p>Security update for go1.20</p> https://cve.radiocsirt.org/vuln/suse-su-2023:2105-2 https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-24536 <p><strong>Affected:</strong> Ubuntu:14.04:LTS: golang-1.10, Ubuntu:Pro:16.04:LTS: golang-1.18, Ubuntu:16.04:LTS: golang-1.10, Ubuntu:16.04:LTS: golang-1.6, Ubuntu:Pro:16.04:LTS: golang-1.13, Ubuntu:18.04:LTS: golang-1.10, Ubuntu:Pro:18.04:LTS: golang-1.13, Ubuntu:Pro:18.04:LTS: golang-1.16, Ubuntu:Pro:18.04:LTS: golang-1.18, Ubuntu:18.04:LTS: golang-1.8 and 8 more</p> <p>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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no mor…</p> <p><strong>Affected:</strong> Ubuntu:14.04:LTS: golang-1.10, Ubuntu:Pro:16.04:LTS: golang-1.18, Ubuntu:16.04:LTS: golang-1.10, Ubuntu:16.04:LTS: golang-1.6, Ubuntu:Pro:16.04:LTS: golang-1.13, Ubuntu:18.04:LTS: golang-1.10, Ubuntu:Pro:18.04:LTS: golang-1.13, Ubuntu:Pro:18.04:LTS: golang-1.16, Ubuntu:Pro:18.04:LTS: golang-1.18, Ubuntu:18.04:LTS: golang-1.8 and 8 more</p> <p>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 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 the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no mor…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-24536 https://cve.radiocsirt.org/vuln/wid-sec-w-2023-1373 <p>Ein Angreifer kann mehrere Schwachstellen in der Red Hat OpenStack Platform ausnutzen, um seine Privilegien zu erhöhen, einen Denial of Service zu verursachen oder Informationen offenzulegen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in der Red Hat OpenStack Platform ausnutzen, um seine Privilegien zu erhöhen, einen Denial of Service zu verursachen oder Informationen offenzulegen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2023-1373