Filtered by vendor Redhat
Subscriptions
Filtered by product Rhosemc
Subscriptions
Total
105 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-44483 | 2 Apache, Redhat | 6 Santuario Xml Security For Java, Apache Camel Spring Boot, Camel Quarkus and 3 more | 2025-02-13 | 6.5 Medium |
| All versions of Apache Santuario - XML Security for Java prior to 2.2.6, 2.3.4, and 3.0.3, when using the JSR 105 API, are vulnerable to an issue where a private key may be disclosed in log files when generating an XML Signature and logging with debug level is enabled. Users are recommended to upgrade to version 2.2.6, 2.3.4, or 3.0.3, which fixes this issue. | ||||
| CVE-2023-2976 | 2 Google, Redhat | 10 Guava, Amq Broker, Amq Streams and 7 more | 2025-02-13 | 5.5 Medium |
| Use of Java's default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class. Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows. | ||||
| CVE-2022-1471 | 2 Redhat, Snakeyaml Project | 14 Amq Clients, Amq Streams, Enterprise Linux and 11 more | 2025-02-13 | 8.3 High |
| SnakeYaml's Constructor() class does not restrict types which can be instantiated during deserialization. Deserializing yaml content provided by an attacker can lead to remote code execution. We recommend using SnakeYaml's SafeConsturctor when parsing untrusted content to restrict deserialization. We recommend upgrading to version 2.0 and beyond. | ||||
| CVE-2023-26049 | 4 Debian, Eclipse, Netapp and 1 more | 15 Debian Linux, Jetty, Active Iq Unified Manager and 12 more | 2025-02-13 | 2.4 Low |
| Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue. | ||||
| CVE-2023-26048 | 2 Eclipse, Redhat | 8 Jetty, Amq Streams, Camel Spring Boot and 5 more | 2025-02-13 | 5.3 Medium |
| Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory). | ||||
| CVE-2023-24538 | 2 Golang, Redhat | 21 Go, Advanced Cluster Security, Ansible Automation Platform and 18 more | 2025-02-13 | 9.8 Critical |
| 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. | ||||
| CVE-2023-24537 | 2 Golang, Redhat | 21 Go, Advanced Cluster Security, Ansible Automation Platform and 18 more | 2025-02-13 | 7.5 High |
| 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. | ||||
| CVE-2023-24536 | 2 Golang, Redhat | 19 Go, Advanced Cluster Security, Ansible Automation Platform and 16 more | 2025-02-13 | 7.5 High |
| 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 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=. | ||||
| CVE-2023-24534 | 2 Golang, Redhat | 22 Go, Advanced Cluster Security, Ansible Automation Platform and 19 more | 2025-02-13 | 7.5 High |
| 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. | ||||
| CVE-2022-41723 | 2 Golang, Redhat | 22 Go, Hpack, Http2 and 19 more | 2025-02-13 | 7.5 High |
| 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. | ||||
| CVE-2022-41715 | 2 Golang, Redhat | 24 Go, Acm, Ceph Storage and 21 more | 2025-02-13 | 7.5 High |
| 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. | ||||
| CVE-2022-2880 | 2 Golang, Redhat | 20 Go, Acm, Ceph Storage and 17 more | 2025-02-13 | 7.5 High |
| 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. | ||||
| CVE-2022-2879 | 2 Golang, Redhat | 16 Go, Container Native Virtualization, Devtools and 13 more | 2025-02-13 | 7.5 High |
| 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. | ||||
| CVE-2024-4629 | 1 Redhat | 12 Build Keycloak, Build Of Keycloak, Enterprise Linux and 9 more | 2025-01-28 | 6.5 Medium |
| A vulnerability was found in Keycloak. This flaw allows attackers to bypass brute force protection by exploiting the timing of login attempts. By initiating multiple login requests simultaneously, attackers can exceed the configured limits for failed attempts before the system locks them out. This timing loophole enables attackers to make more guesses at passwords than intended, potentially compromising account security on affected systems. | ||||
| CVE-2023-29400 | 2 Golang, Redhat | 22 Go, Acm, Advanced Cluster Security and 19 more | 2025-01-24 | 7.3 High |
| Templates containing actions in unquoted HTML attributes (e.g. "attr={{.}}") executed with empty input can result in output with unexpected results when parsed due to HTML normalization rules. This may allow injection of arbitrary attributes into tags. | ||||
| CVE-2023-24540 | 2 Golang, Redhat | 20 Go, Acm, Advanced Cluster Security and 17 more | 2025-01-24 | 9.8 Critical |
| 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. | ||||
| CVE-2023-24539 | 2 Golang, Redhat | 22 Go, Acm, Advanced Cluster Security and 19 more | 2025-01-24 | 7.3 High |
| Angle brackets (<>) are not considered dangerous characters when inserted into CSS contexts. Templates containing multiple actions separated by a '/' character can result in unexpectedly closing the CSS context and allowing for injection of unexpected HTML, if executed with untrusted input. | ||||
| CVE-2023-1664 | 1 Redhat | 8 Amq Broker, Build Of Quarkus, Jboss A-mq and 5 more | 2025-01-15 | 6.5 Medium |
| A flaw was found in Keycloak. This flaw depends on a non-default configuration "Revalidate Client Certificate" to be enabled and the reverse proxy is not validating the certificate before Keycloak. Using this method an attacker may choose the certificate which will be validated by the server. If this happens and the KC_SPI_TRUSTSTORE_FILE_FILE variable is missing/misconfigured, any trustfile may be accepted with the logging information of "Cannot validate client certificate trust: Truststore not available". This may not impact availability as the attacker would have no access to the server, but consumer applications Integrity or Confidentiality may be impacted considering a possible access to them. Considering the environment is correctly set to use "Revalidate Client Certificate" this flaw is avoidable. | ||||
| CVE-2024-7341 | 1 Redhat | 8 Build Keycloak, Build Of Keycloak, Enterprise Linux and 5 more | 2024-12-31 | 7.1 High |
| A session fixation issue was discovered in the SAML adapters provided by Keycloak. The session ID and JSESSIONID cookie are not changed at login time, even when the turnOffChangeSessionIdOnLogin option is configured. This flaw allows an attacker who hijacks the current session before authentication to trigger session fixation. | ||||
| CVE-2024-8883 | 1 Redhat | 10 Build Keycloak, Build Of Keycloak, Jboss Enterprise Application Platform and 7 more | 2024-12-24 | 6.1 Medium |
| A misconfiguration flaw was found in Keycloak. This issue can allow an attacker to redirect users to an arbitrary URL if a 'Valid Redirect URI' is set to http://localhost or http://127.0.0.1, enabling sensitive information such as authorization codes to be exposed to the attacker, potentially leading to session hijacking. | ||||