Filtered by vendor Apache
Subscribe
Total
2295 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2021-26291 | 3 Apache, Oracle, Quarkus | 4 Maven, Financial Services Analytical Applications Infrastructure, Goldengate Big Data And Application Adapters and 1 more | 2024-11-21 | 6.4 MEDIUM | 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-26118 | 2 Apache, Netapp | 2 Activemq Artemis, Oncommand Workflow Automation | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| While investigating ARTEMIS-2964 it was found that the creation of advisory messages in the OpenWire protocol head of Apache ActiveMQ Artemis 2.15.0 bypassed policy based access control for the entire session. Production of advisory messages was not subject to access control in error. | |||||
| CVE-2021-26117 | 4 Apache, Debian, Netapp and 1 more | 8 Activemq, Activemq Artemis, Debian Linux and 5 more | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| The optional ActiveMQ LDAP login module can be configured to use anonymous access to the LDAP server. In this case, for Apache ActiveMQ Artemis prior to version 2.16.0 and Apache ActiveMQ prior to versions 5.16.1 and 5.15.14, the anonymous context is used to verify a valid users password in error, resulting in no check on the password. | |||||
| CVE-2021-25958 | 1 Apache | 1 Ofbiz | 2024-11-21 | 5.0 MEDIUM | 6.5 MEDIUM |
| In Apache Ofbiz, versions v17.12.01 to v17.12.07 implement a try catch exception to handle errors at multiple locations but leaks out sensitive table info which may aid the attacker for further recon. A user can register with a very long password, but when he tries to login with it an exception occurs. | |||||
| CVE-2021-25646 | 1 Apache | 1 Druid | 2024-11-21 | 9.0 HIGH | 8.8 HIGH |
| Apache Druid includes the ability to execute user-provided JavaScript code embedded in various types of requests. This functionality is intended for use in high-trust environments, and is disabled by default. However, in Druid 0.20.0 and earlier, it is possible for an authenticated user to send a specially-crafted request that forces Druid to run user-provided JavaScript code for that request, regardless of server configuration. This can be leveraged to execute code on the target machine with the privileges of the Druid server process. | |||||
| CVE-2021-25642 | 1 Apache | 1 Hadoop | 2024-11-21 | N/A | 8.8 HIGH |
| ZKConfigurationStore which is optionally used by CapacityScheduler of Apache Hadoop YARN deserializes data obtained from ZooKeeper without validation. An attacker having access to ZooKeeper can run arbitrary commands as YARN user by exploiting this. Users should upgrade to Apache Hadoop 2.10.2, 3.2.4, 3.3.4 or later (containing YARN-11126) if ZKConfigurationStore is used. | |||||
| CVE-2021-25641 | 1 Apache | 1 Dubbo | 2024-11-21 | 7.5 HIGH | 9.8 CRITICAL |
| Each Apache Dubbo server will set a serialization id to tell the clients which serialization protocol it is working on. But for Dubbo versions before 2.7.8 or 2.6.9, an attacker can choose which serialization id the Provider will use by tampering with the byte preamble flags, aka, not following the server's instruction. This means that if a weak deserializer such as the Kryo and FST are somehow in code scope (e.g. if Kryo is somehow a part of a dependency), a remote unauthenticated attacker can tell the Provider to use the weak deserializer, and then proceed to exploit it. | |||||
| CVE-2021-25640 | 1 Apache | 1 Dubbo | 2024-11-21 | 5.8 MEDIUM | 6.1 MEDIUM |
| In Apache Dubbo prior to 2.6.9 and 2.7.9, the usage of parseURL method will lead to the bypass of white host check which can cause open redirect or SSRF vulnerability. | |||||
| CVE-2021-25329 | 3 Apache, Debian, Oracle | 12 Tomcat, Debian Linux, Agile Plm and 9 more | 2024-11-21 | 4.4 MEDIUM | 7.0 HIGH |
| The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue. | |||||
| CVE-2021-25122 | 3 Apache, Debian, Oracle | 12 Tomcat, Debian Linux, Agile Plm and 9 more | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| When responding to new h2c connection requests, Apache Tomcat versions 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request. | |||||
| CVE-2021-24122 | 3 Apache, Debian, Oracle | 3 Tomcat, Debian Linux, Agile Plm | 2024-11-21 | 4.3 MEDIUM | 5.9 MEDIUM |
| When serving resources from a network location using the NTFS file system, Apache Tomcat versions 10.0.0-M1 to 10.0.0-M9, 9.0.0.M1 to 9.0.39, 8.5.0 to 8.5.59 and 7.0.0 to 7.0.106 were susceptible to JSP source code disclosure in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances. | |||||
| CVE-2021-24117 | 1 Apache | 1 Teaclave Sgx Sdk | 2024-11-21 | 4.0 MEDIUM | 4.9 MEDIUM |
| In Apache Teaclave Rust SGX SDK 1.1.3, a side-channel vulnerability in base64 PEM file decoding allows system-level (administrator) attackers to obtain information about secret RSA keys via a controlled-channel and side-channel attack on software running in isolated environments that can be single stepped, especially Intel SGX. | |||||
| CVE-2021-23937 | 1 Apache | 1 Wicket | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| A DNS proxy and possible amplification attack vulnerability in WebClientInfo of Apache Wicket allows an attacker to trigger arbitrary DNS lookups from the server when the X-Forwarded-For header is not properly sanitized. This DNS lookup can be engineered to overload an internal DNS server or to slow down request processing of the Apache Wicket application causing a possible denial of service on either the internal infrastructure or the web application itself. This issue affects Apache Wicket Apache Wicket 9.x version 9.2.0 and prior versions; Apache Wicket 8.x version 8.11.0 and prior versions; Apache Wicket 7.x version 7.17.0 and prior versions and Apache Wicket 6.x version 6.2.0 and later versions. | |||||
| CVE-2021-23926 | 4 Apache, Debian, Netapp and 1 more | 7 Xmlbeans, Debian Linux, Oncommand Unified Manager Core Package and 4 more | 2024-11-21 | 6.4 MEDIUM | 9.1 CRITICAL |
| The XML parsers used by XMLBeans up to version 2.6.0 did not set the properties needed to protect the user from malicious XML input. Vulnerabilities include possibilities for XML Entity Expansion attacks. Affects XMLBeans up to and including v2.6.0. | |||||
| CVE-2021-23901 | 2 Apache, Netapp | 2 Nutch, Snap Creator Framework | 2024-11-21 | 6.4 MEDIUM | 9.1 CRITICAL |
| An XML external entity (XXE) injection vulnerability was discovered in the Nutch DmozParser and is known to affect Nutch versions < 1.18. XML external entity injection (also known as XXE) is a web security vulnerability that allows an attacker to interfere with an application's processing of XML data. It often allows an attacker to view files on the application server filesystem, and to interact with any back-end or external systems that the application itself can access. This issue is fixed in Apache Nutch 1.18. | |||||
| CVE-2021-22696 | 2 Apache, Oracle | 6 Cxf, Business Intelligence, Communications Diameter Intelligence Hub and 3 more | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| CXF supports (via JwtRequestCodeFilter) passing OAuth 2 parameters via a JWT token as opposed to query parameters (see: The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)). Instead of sending a JWT token as a "request" parameter, the spec also supports specifying a URI from which to retrieve a JWT token from via the "request_uri" parameter. CXF was not validating the "request_uri" parameter (apart from ensuring it uses "https) and was making a REST request to the parameter in the request to retrieve a token. This means that CXF was vulnerable to DDos attacks on the authorization server, as specified in section 10.4.1 of the spec. This issue affects Apache CXF versions prior to 3.4.3; Apache CXF versions prior to 3.3.10. | |||||
| CVE-2021-22160 | 1 Apache | 1 Pulsar | 2024-11-21 | 7.5 HIGH | 9.8 CRITICAL |
| If Apache Pulsar is configured to authenticate clients using tokens based on JSON Web Tokens (JWT), the signature of the token is not validated if the algorithm of the presented token is set to "none". This allows an attacker to connect to Pulsar instances as any user (incl. admins). | |||||
| CVE-2021-21501 | 1 Apache | 1 Servicecomb | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| Improper configuration will cause ServiceComb ServiceCenter Directory Traversal problem in ServcieCenter 1.x.x versions and fixed in 2.0.0. | |||||
| CVE-2021-21315 | 2 Apache, Systeminformation | 2 Cordova, Systeminformation | 2024-11-21 | 4.6 MEDIUM | 7.1 HIGH |
| The System Information Library for Node.JS (npm package "systeminformation") is an open source collection of functions to retrieve detailed hardware, system and OS information. In systeminformation before version 5.3.1 there is a command injection vulnerability. Problem was fixed in version 5.3.1. As a workaround instead of upgrading, be sure to check or sanitize service parameters that are passed to si.inetLatency(), si.inetChecksite(), si.services(), si.processLoad() ... do only allow strings, reject any arrays. String sanitation works as expected. | |||||
| CVE-2021-21295 | 6 Apache, Debian, Netapp and 3 more | 8 Kudu, Zookeeper, Debian Linux and 5 more | 2024-11-21 | 2.6 LOW | 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`. | |||||