Filtered by vendor Redhat
Subscriptions
Filtered by product Jboss Amq
Subscriptions
Total
102 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-46604 | 4 Apache, Debian, Netapp and 1 more | 10 Activemq, Activemq Legacy Openwire Module, Debian Linux and 7 more | 2025-02-13 | 10 Critical |
| The Java OpenWire protocol marshaller is vulnerable to Remote Code Execution. This vulnerability may allow a remote attacker with network access to either a Java-based OpenWire broker or client to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause either the client or the broker (respectively) to instantiate any class on the classpath. Users are recommended to upgrade both brokers and clients to version 5.15.16, 5.16.7, 5.17.6, or 5.18.3 which fixes this issue. | ||||
| CVE-2014-3120 | 3 Elasticsearch, Redhat, Rhel Sam | 7 Elasticsearch, Fuse Esb Enterprise, Fuse Management Console and 4 more | 2025-02-10 | 8.1 High |
| The default configuration in Elasticsearch before 1.2 enables dynamic scripting, which allows remote attackers to execute arbitrary MVEL expressions and Java code via the source parameter to _search. NOTE: this only violates the vendor's intended security policy if the user does not run Elasticsearch in its own independent virtual machine. | ||||
| CVE-2015-1427 | 2 Elastic, Redhat | 4 Elasticsearch, Fuse, Jboss Amq and 1 more | 2025-02-10 | 9.8 Critical |
| The Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted script. | ||||
| CVE-2016-4437 | 2 Apache, Redhat | 6 Aurora, Shiro, Fuse and 3 more | 2025-02-07 | 9.8 Critical |
| Apache Shiro before 1.2.5, when a cipher key has not been configured for the "remember me" feature, allows remote attackers to execute arbitrary code or bypass intended access restrictions via an unspecified request parameter. | ||||
| CVE-2016-3088 | 2 Apache, Redhat | 3 Activemq, Jboss Amq, Jboss Fuse | 2025-02-07 | 9.8 Critical |
| The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows remote attackers to upload and execute arbitrary files via an HTTP PUT followed by an HTTP MOVE request. | ||||
| CVE-2022-23307 | 4 Apache, Oracle, Qos and 1 more | 44 Chainsaw, Log4j, Advanced Supply Chain Planning and 41 more | 2024-11-21 | 8.8 High |
| CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists. | ||||
| CVE-2022-23305 | 6 Apache, Broadcom, Netapp and 3 more | 46 Log4j, Brocade Sannav, Snapmanager and 43 more | 2024-11-21 | 9.8 Critical |
| By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions. | ||||
| CVE-2022-23302 | 6 Apache, Broadcom, Netapp and 3 more | 44 Log4j, Brocade Sannav, Snapmanager and 41 more | 2024-11-21 | 8.8 High |
| JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions. | ||||
| CVE-2021-4104 | 4 Apache, Fedoraproject, Oracle and 1 more | 59 Log4j, Fedora, Advanced Supply Chain Planning and 56 more | 2024-11-21 | 7.5 High |
| JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration. The attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-44228. Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions. | ||||
| CVE-2021-26117 | 5 Apache, Debian, Netapp and 2 more | 10 Activemq, Activemq Artemis, Debian Linux and 7 more | 2024-11-21 | 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-2020-26217 | 6 Apache, Debian, Netapp and 3 more | 23 Activemq, Debian Linux, Snapmanager and 20 more | 2024-11-21 | 8 High |
| XStream before version 1.4.14 is vulnerable to Remote Code Execution.The vulnerability may allow a remote attacker to run arbitrary shell commands only by manipulating the processed input stream. Only users who rely on blocklists are affected. Anyone using XStream's Security Framework allowlist is not affected. The linked advisory provides code workarounds for users who cannot upgrade. The issue is fixed in version 1.4.14. | ||||
| CVE-2020-13933 | 3 Apache, Debian, Redhat | 4 Shiro, Debian Linux, Jboss Amq and 1 more | 2024-11-21 | 7.5 High |
| Apache Shiro before 1.6.0, when using Apache Shiro, a specially crafted HTTP request may cause an authentication bypass. | ||||
| CVE-2019-9827 | 2 Hawt, Redhat | 4 Hawtio, Amq Broker, Jboss Amq and 1 more | 2024-11-21 | N/A |
| Hawt Hawtio through 2.5.0 is vulnerable to SSRF, allowing a remote attacker to trigger an HTTP request from an affected server to an arbitrary host via the initial /proxy/ substring of a URI. | ||||
| CVE-2019-12814 | 3 Debian, Fasterxml, Redhat | 12 Debian Linux, Jackson-databind, Amq Streams and 9 more | 2024-11-21 | 5.9 Medium |
| A Polymorphic Typing issue was discovered in FasterXML jackson-databind 2.x through 2.9.9. When Default Typing is enabled (either globally or for a specific property) for an externally exposed JSON endpoint and the service has JDOM 1.x or 2.x jar in the classpath, an attacker can send a specifically crafted JSON message that allows them to read arbitrary local files on the server. | ||||
| CVE-2019-0201 | 5 Apache, Debian, Netapp and 2 more | 14 Activemq, Drill, Zookeeper and 11 more | 2024-11-21 | 5.9 Medium |
| An issue is present in Apache ZooKeeper 1.0.0 to 3.4.13 and 3.5.0-alpha to 3.5.4-beta. ZooKeeper’s getACL() command doesn’t check any permission when retrieves the ACLs of the requested node and returns all information contained in the ACL Id field as plaintext string. DigestAuthenticationProvider overloads the Id field with the hash value that is used for user authentication. As a consequence, if Digest Authentication is in use, the unsalted hash value will be disclosed by getACL() request for unauthenticated or unprivileged users. | ||||
| CVE-2018-9159 | 2 Redhat, Sparkjava | 3 Jboss Amq, Jboss Fuse, Spark | 2024-11-21 | N/A |
| In Spark before 2.7.2, a remote attacker can read unintended static files via various representations of absolute or relative pathnames, as demonstrated by file: URLs and directory traversal sequences. NOTE: this product is unrelated to Ignite Realtime Spark. | ||||
| CVE-2018-8039 | 2 Apache, Redhat | 6 Cxf, Enterprise Linux, Jboss Amq and 3 more | 2024-11-21 | N/A |
| It is possible to configure Apache CXF to use the com.sun.net.ssl implementation via 'System.setProperty("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol");'. When this system property is set, CXF uses some reflection to try to make the HostnameVerifier work with the old com.sun.net.ssl.HostnameVerifier interface. However, the default HostnameVerifier implementation in CXF does not implement the method in this interface, and an exception is thrown. However, in Apache CXF prior to 3.2.5 and 3.1.16 the exception is caught in the reflection code and not properly propagated. What this means is that if you are using the com.sun.net.ssl stack with CXF, an error with TLS hostname verification will not be thrown, leaving a CXF client subject to man-in-the-middle attacks. | ||||
| CVE-2018-10899 | 2 Jolokia, Redhat | 4 Jolokia, Jboss Amq, Jboss Fuse and 1 more | 2024-11-21 | N/A |
| A flaw was found in Jolokia versions from 1.2 to before 1.6.1. Affected versions are vulnerable to a system-wide CSRF. This holds true for properly configured instances with strict checking for origin and referrer headers. This could result in a Remote Code Execution attack. | ||||
| CVE-2018-1000129 | 2 Jolokia, Redhat | 3 Jolokia, Jboss Amq, Jboss Fuse | 2024-11-21 | N/A |
| An XSS vulnerability exists in the Jolokia agent version 1.3.7 in the HTTP servlet that allows an attacker to execute malicious javascript in the victim's browser. | ||||
| CVE-2017-8028 | 3 Debian, Pivotal Software, Redhat | 4 Debian Linux, Spring-ldap, Jboss Amq and 1 more | 2024-11-21 | N/A |
| In Pivotal Spring-LDAP versions 1.3.0 - 2.3.1, when connected to some LDAP servers, when no additional attributes are bound, and when using LDAP BindAuthenticator with org.springframework.ldap.core.support.DefaultTlsDirContextAuthenticationStrategy as the authentication strategy, and setting userSearch, authentication is allowed with an arbitrary password when the username is correct. This occurs because some LDAP vendors require an explicit operation for the LDAP bind to take effect. | ||||