https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 11:03:29 +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-01979 bdu:2024-01979 https://cve.radiocsirt.org/vuln/bdu:2024-01979 https://cve.radiocsirt.org/vuln/bell-cve-2023-24538 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Withdrawn by the publisher.</strong></p> https://cve.radiocsirt.org/vuln/bell-cve-2023-24538 https://cve.radiocsirt.org/vuln/bit-golang-2023-24538 <p><strong>Affected:</strong> Bitnami: golang</p> <p>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. &#34;var a = {{.}}&#34;), 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.</p> <p><strong>Affected:</strong> Bitnami: golang</p> <p>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. &#34;var a = {{.}}&#34;), 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.</p> https://cve.radiocsirt.org/vuln/bit-golang-2023-24538 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-216305 EUVD-2026-216305 https://cve.radiocsirt.org/vuln/euvd-2026-216305 https://cve.radiocsirt.org/vuln/fkie_cve-2023-24538 <p>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. &#34;var a = {{.}}&#34;), 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.</p> <p>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. &#34;var a = {{.}}&#34;), 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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2023-24538 https://cve.radiocsirt.org/vuln/ghsa-v4m2-x4rp-hv22 <p>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. &#34;var a = {{.}}&#34;), 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.</p> <p>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. &#34;var a = {{.}}&#34;), 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.</p> https://cve.radiocsirt.org/vuln/ghsa-v4m2-x4rp-hv22 https://cve.radiocsirt.org/vuln/gsd-2023-24538 gsd-2023-24538 https://cve.radiocsirt.org/vuln/gsd-2023-24538 https://cve.radiocsirt.org/vuln/icsa-24-046-11 <p>A carefully crafted If: request header can cause a memory read, or write of a single zero byte, in a pool (heap) memory location beyond the header value sent. This could cause the process to crash.</p> <p>This issue affects Apache HTTP Server 2.4.54 and earlier. A flaw was found in python. In algorithms with quadratic time complexity using non-binary bases, when using int(&#34;text&#34;), a system could take 50ms to parse an int string with 100,000 digits and 5s for 1,000,000 digits (float, decimal, int.from_bytes(), and int() for binary bases 2, 4, 8, 16, and 32 are not affected). The highest threat from this vulnerability is to system availability. A flaw was found in libdnf&#39;s signature verification functionality in versions before 0.60.1. This flaw allows an attacker to achieve code execution if they can alter the header information of an RPM package and then trick a user or system into installing it. The highest risk of this vulnerability is to confidentiality, integrity, as well as system availability. An out-of-bounds memory access flaw was found in the ATI VGA device emulation of QEMU. This flaw occurs in the ati_2d_blt() routine while handling MMIO write operations when the guest provides invalid values for the destination display parameters. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service. A vulnerability was found in the fs/inode.c:inode_init_owner() function logic of the LInux kernel that allows local users to create…</p> <p>A carefully crafted If: request header can cause a memory read, or write of a single zero byte, in a pool (heap) memory location beyond the header value sent. This could cause the process to crash.</p> <p>This issue affects Apache HTTP Server 2.4.54 and earlier. A flaw was found in python. In algorithms with quadratic time complexity using non-binary bases, when using int(&#34;text&#34;), a system could take 50ms to parse an int string with 100,000 digits and 5s for 1,000,000 digits (float, decimal, int.from_bytes(), and int() for binary bases 2, 4, 8, 16, and 32 are not affected). The highest threat from this vulnerability is to system availability. A flaw was found in libdnf&#39;s signature verification functionality in versions before 0.60.1. This flaw allows an attacker to achieve code execution if they can alter the header information of an RPM package and then trick a user or system into installing it. The highest risk of this vulnerability is to confidentiality, integrity, as well as system availability. An out-of-bounds memory access flaw was found in the ATI VGA device emulation of QEMU. This flaw occurs in the ati_2d_blt() routine while handling MMIO write operations when the guest provides invalid values for the destination display parameters. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service. A vulnerability was found in the fs/inode.c:inode_init_owner() function logic of the LInux kernel that allows local users to create…</p> https://cve.radiocsirt.org/vuln/icsa-24-046-11 https://cve.radiocsirt.org/vuln/msrc_cve-2023-24538 msrc_CVE-2023-24538 https://cve.radiocsirt.org/vuln/msrc_cve-2023-24538 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-24538 <p><strong>Affected:</strong> Ubuntu:14.04:LTS: golang-1.10, Ubuntu:Pro:16.04:LTS: golang-1.13, Ubuntu:16.04:LTS: golang-1.10, Ubuntu:16.04:LTS: golang-1.6, Ubuntu:18.04:LTS: golang-1.18, Ubuntu:18.04:LTS: golang-1.10, Ubuntu:Pro:18.04:LTS: golang-1.13, Ubuntu:Pro:18.04:LTS: golang-1.16, Ubuntu:18.04:LTS: golang-1.8, Ubuntu:18.04:LTS: golang-1.9 and 7 more</p> <p>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. &#34;var a = {{.}}&#34;), 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.</p> <p><strong>Affected:</strong> Ubuntu:14.04:LTS: golang-1.10, Ubuntu:Pro:16.04:LTS: golang-1.13, Ubuntu:16.04:LTS: golang-1.10, Ubuntu:16.04:LTS: golang-1.6, Ubuntu:18.04:LTS: golang-1.18, Ubuntu:18.04:LTS: golang-1.10, Ubuntu:Pro:18.04:LTS: golang-1.13, Ubuntu:Pro:18.04:LTS: golang-1.16, Ubuntu:18.04:LTS: golang-1.8, Ubuntu:18.04:LTS: golang-1.9 and 7 more</p> <p>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. &#34;var a = {{.}}&#34;), 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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-24538 https://cve.radiocsirt.org/vuln/wid-sec-w-2023-1378 <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in der Red Hat OpenShift Container Platform ausnutzen, um Sicherheitsvorkehrungen zu umgehen.</p> <p>Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in der Red Hat OpenShift Container Platform ausnutzen, um Sicherheitsvorkehrungen zu umgehen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2023-1378