Filtered by vendor Quarkus
Subscriptions
Total
45 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2021-38153 | 4 Apache, Oracle, Quarkus and 1 more | 15 Kafka, Communications Brm - Elastic Charging Engine, Communications Cloud Native Core Policy and 12 more | 2024-08-04 | 5.9 Medium |
| Some components in Apache Kafka use `Arrays.equals` to validate a password or key, which is vulnerable to timing attacks that make brute force attacks for such credentials more likely to be successful. Users should upgrade to 2.8.1 or higher, or 3.0.0 or higher where this vulnerability has been fixed. The affected versions include Apache Kafka 2.0.0, 2.0.1, 2.1.0, 2.1.1, 2.2.0, 2.2.1, 2.2.2, 2.3.0, 2.3.1, 2.4.0, 2.4.1, 2.5.0, 2.5.1, 2.6.0, 2.6.1, 2.6.2, 2.7.0, 2.7.1, and 2.8.0. | ||||
| CVE-2021-37714 | 5 Jsoup, Netapp, Oracle and 2 more | 24 Jsoup, Management Services For Element Software And Netapp Hci, Banking Trade Finance and 21 more | 2024-08-04 | 7.5 High |
| jsoup is a Java library for working with HTML. Those using jsoup versions prior to 1.14.2 to parse untrusted HTML or XML may be vulnerable to DOS attacks. If the parser is run on user supplied input, an attacker may supply content that causes the parser to get stuck (loop indefinitely until cancelled), to complete more slowly than usual, or to throw an unexpected exception. This effect may support a denial of service attack. The issue is patched in version 1.14.2. There are a few available workarounds. Users may rate limit input parsing, limit the size of inputs based on system resources, and/or implement thread watchdogs to cap and timeout parse runtimes. | ||||
| CVE-2021-37137 | 6 Debian, Netapp, Netty and 3 more | 23 Debian Linux, Oncommand Insight, Netty and 20 more | 2024-08-04 | 7.5 High |
| The Snappy frame decoder function doesn't restrict the chunk length which may lead to excessive memory usage. Beside this it also may buffer reserved skippable chunks until the whole chunk was received which may lead to excessive memory usage as well. This vulnerability can be triggered by supplying malicious input that decompresses to a very big size (via a network stream or a file) or by sending a huge skippable chunk. | ||||
| CVE-2021-37136 | 6 Debian, Netapp, Netty and 3 more | 30 Debian Linux, Oncommand Insight, Netty and 27 more | 2024-08-04 | 7.5 High |
| The Bzip2 decompression decoder function doesn't allow setting size restrictions on the decompressed output data (which affects the allocation size used during decompression). All users of Bzip2Decoder are affected. The malicious input can trigger an OOME and so a DoS attack | ||||
| CVE-2021-29429 | 3 Gradle, Quarkus, Redhat | 4 Gradle, Quarkus, Camel Quarkus and 1 more | 2024-08-03 | 4 Medium |
| In Gradle before version 7.0, files created with open permissions in the system temporary directory can allow an attacker to access information downloaded by Gradle. Some builds could be vulnerable to a local information disclosure. Remote files accessed through TextResourceFactory are downloaded into the system temporary directory first. Sensitive information contained in these files can be exposed to other local users on the same system. If you do not use the `TextResourceFactory` API, you are not vulnerable. As of Gradle 7.0, uses of the system temporary directory have been moved to the Gradle User Home directory. By default, this directory is restricted to the user running the build. As a workaround, set a more restrictive umask that removes read access to other users. When files are created in the system temporary directory, they will not be accessible to other users. If you are unable to change your system's umask, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. | ||||
| CVE-2021-29428 | 3 Gradle, Quarkus, Redhat | 3 Gradle, Quarkus, Quarkus | 2024-08-03 | 8.8 High |
| In Gradle before version 7.0, on Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. Gradle builds could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. This vulnerability impacted builds using precompiled script plugins written in Kotlin DSL and tests for Gradle plugins written using ProjectBuilder or TestKit. If you are on Windows or modern versions of macOS, you are not vulnerable. If you are on a Unix-like operating system with the "sticky" bit set on your system temporary directory, you are not vulnerable. The problem has been patched and released with Gradle 7.0. As a workaround, on Unix-like operating systems, ensure that the "sticky" bit is set. This only allows the original user (or root) to delete a file. If you are unable to change the permissions of the system temporary directory, you can move the Java temporary directory by setting the System Property `java.io.tmpdir`. The new path needs to limit permissions to the build user only. For additional details refer to the referenced GitHub Security Advisory. | ||||
| CVE-2021-29427 | 3 Gradle, Quarkus, Redhat | 3 Gradle, Quarkus, Quarkus | 2024-08-03 | 8 High |
| In Gradle from version 5.1 and before version 7.0 there is a vulnerability which can lead to information disclosure and/or dependency poisoning. Repository content filtering is a security control Gradle introduced to help users specify what repositories are used to resolve specific dependencies. This feature was introduced in the wake of the "A Confusing Dependency" blog post. In some cases, Gradle may ignore content filters and search all repositories for dependencies. This only occurs when repository content filtering is used from within a `pluginManagement` block in a settings file. This may change how dependencies are resolved for Gradle plugins and build scripts. For builds that are vulnerable, there are two risks: 1) Information disclosure: Gradle could make dependency requests to repositories outside your organization and leak internal package identifiers. 2) Dependency poisoning/Dependency confusion: Gradle could download a malicious binary from a repository outside your organization due to name squatting. For a full example and more details refer to the referenced GitHub Security Advisory. The problem has been patched and released with Gradle 7.0. Users relying on this feature should upgrade their build as soon as possible. As a workaround, users may use a company repository which has the right rules for fetching packages from public repositories, or use project level repository content filtering, inside `buildscript.repositories`. This option is available since Gradle 5.1 when the feature was introduced. | ||||
| CVE-2021-28170 | 4 Eclipse, Oracle, Quarkus and 1 more | 11 Jakarta Expression Language, Communications Cloud Native Core Policy, Weblogic Server and 8 more | 2024-08-03 | 5.3 Medium |
| In the Jakarta Expression Language implementation 3.0.3 and earlier, a bug in the ELParserTokenManager enables invalid EL expressions to be evaluated as if they were valid. | ||||
| CVE-2021-26291 | 4 Apache, Oracle, Quarkus and 1 more | 9 Maven, Financial Services Analytical Applications Infrastructure, Goldengate Big Data And Application Adapters and 6 more | 2024-08-03 | 9.1 Critical |
| Apache Maven will follow repositories that are defined in a dependency’s Project Object Model (pom) which may be surprising to some users, resulting in potential risk if a malicious actor takes over that repository or is able to insert themselves into a position to pretend to be that repository. Maven is changing the default behavior in 3.8.1+ to no longer follow http (non-SSL) repository references by default. More details available in the referenced urls. If you are currently using a repository manager to govern the repositories used by your builds, you are unaffected by the risks present in the legacy behavior, and are unaffected by this vulnerability and change to default behavior. See this link for more information about repository management: https://maven.apache.org/repository-management.html | ||||
| CVE-2021-21409 | 6 Debian, Netapp, Netty and 3 more | 29 Debian Linux, Oncommand Api Services, Oncommand Workflow Automation and 26 more | 2024-08-03 | 5.9 Medium |
| Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.61.Final there is a vulnerability that enables request smuggling. The content-length header is not correctly validated if the request only uses a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1. This is a followup of GHSA-wm47-8v5p-wjpj/CVE-2021-21295 which did miss to fix this one case. This was fixed as part of 4.1.61.Final. | ||||
| CVE-2021-21290 | 6 Debian, Netapp, Netty and 3 more | 27 Debian Linux, Active Iq Unified Manager, Cloud Secure Agent and 24 more | 2024-08-03 | 6.2 Medium |
| Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method "File.createTempFile" on unix-like systems creates a random file, but, by default will create this file with the permissions "-rw-r--r--". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's "AbstractDiskHttpData" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own "java.io.tmpdir" when you start the JVM or use "DefaultHttpDataFactory.setBaseDir(...)" to set the directory to something that is only readable by the current user. | ||||
| CVE-2021-21295 | 7 Apache, Debian, Netapp and 4 more | 19 Kudu, Zookeeper, Debian Linux and 16 more | 2024-08-03 | 5.9 Medium |
| Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`. | ||||
| CVE-2021-20289 | 4 Netapp, Oracle, Quarkus and 1 more | 12 Oncommand Insight, Communications Cloud Native Core Console, Quarkus and 9 more | 2024-08-03 | 5.3 Medium |
| A flaw was found in RESTEasy in all versions of RESTEasy up to 4.6.0.Final. The endpoint class and method names are returned as part of the exception response when RESTEasy cannot convert one of the request URI path or query values to the matching JAX-RS resource method's parameter value. The highest threat from this vulnerability is to data confidentiality. | ||||
| CVE-2021-3642 | 2 Quarkus, Redhat | 18 Quarkus, Build Of Quarkus, Camel Quarkus and 15 more | 2024-08-03 | 5.3 Medium |
| A flaw was found in Wildfly Elytron in versions prior to 1.10.14.Final, prior to 1.15.5.Final and prior to 1.16.1.Final where ScramServer may be susceptible to Timing Attack if enabled. The highest threat of this vulnerability is confidentiality. | ||||
| CVE-2022-42004 | 5 Debian, Fasterxml, Netapp and 2 more | 19 Debian Linux, Jackson-databind, Oncommand Workflow Automation and 16 more | 2024-08-03 | 7.5 High |
| In FasterXML jackson-databind before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer._deserializeFromArray to prevent use of deeply nested arrays. An application is vulnerable only with certain customized choices for deserialization. | ||||
| CVE-2022-42003 | 5 Debian, Fasterxml, Netapp and 2 more | 20 Debian Linux, Jackson-databind, Oncommand Workflow Automation and 17 more | 2024-08-03 | 7.5 High |
| In FasterXML jackson-databind before versions 2.13.4.1 and 2.12.17.1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled. | ||||
| CVE-2022-21724 | 5 Debian, Fedoraproject, Postgresql and 2 more | 8 Debian Linux, Fedora, Postgresql Jdbc Driver and 5 more | 2024-08-03 | 7 High |
| pgjdbc is the offical PostgreSQL JDBC Driver. A security hole was found in the jdbc driver for postgresql database while doing security research. The system using the postgresql library will be attacked when attacker control the jdbc url or properties. pgjdbc instantiates plugin instances based on class names provided via `authenticationPluginClassName`, `sslhostnameverifier`, `socketFactory`, `sslfactory`, `sslpasswordcallback` connection properties. However, the driver did not verify if the class implements the expected interface before instantiating the class. This can lead to code execution loaded via arbitrary classes. Users using plugins are advised to upgrade. There are no known workarounds for this issue. | ||||
| CVE-2022-4147 | 2 Quarkus, Redhat | 2 Quarkus, Quarkus | 2024-08-03 | 7.5 High |
| Quarkus CORS filter allows simple GET and POST requests with invalid Origin to proceed. Simple GET or POST requests made with XMLHttpRequest are the ones which have no event listeners registered on the object returned by the XMLHttpRequest upload property and have no ReadableStream object used in the request. | ||||
| CVE-2022-4116 | 2 Quarkus, Redhat | 3 Quarkus, Build Of Quarkus, Quarkus | 2024-08-03 | 9.8 Critical |
| A vulnerability was found in quarkus. This security flaw happens in Dev UI Config Editor which is vulnerable to drive-by localhost attacks leading to remote code execution. | ||||
| CVE-2022-2466 | 1 Quarkus | 1 Quarkus | 2024-08-03 | 9.8 Critical |
| It was found that Quarkus 2.10.x does not terminate HTTP requests header context which may lead to unpredictable behavior. | ||||