Filtered by vendor Redhat
Subscriptions
Filtered by product Jboss Fuse
Subscriptions
Total
567 CVE
CVE | Vendors | Products | Updated | CVSS v3.1 |
---|---|---|---|---|
CVE-2017-12626 | 2 Apache, Redhat | 3 Poi, Jboss Amq, Jboss Fuse | 2024-11-21 | N/A |
Apache POI in versions prior to release 3.17 are vulnerable to Denial of Service Attacks: 1) Infinite Loops while parsing crafted WMF, EMF, MSG and macros (POI bugs 61338 and 61294), and 2) Out of Memory Exceptions while parsing crafted DOC, PPT and XLS (POI bugs 52372 and 61295). | ||||
CVE-2017-12196 | 1 Redhat | 6 Enterprise Linux, Jboss Enterprise Application Platform, Jboss Enterprise Application Platform Cd and 3 more | 2024-11-21 | N/A |
undertow before versions 1.4.18.SP1, 2.0.2.Final, 1.4.24.Final was found vulnerable when using Digest authentication, the server does not ensure that the value of URI in the Authorization header matches the URI in HTTP request line. This allows the attacker to cause a MITM attack and access the desired content on the server. | ||||
CVE-2017-12165 | 1 Redhat | 4 Jboss Amq, Jboss Enterprise Application Platform, Jboss Fuse and 1 more | 2024-11-21 | N/A |
It was discovered that Undertow before 1.4.17, 1.3.31 and 2.0.0 processes http request headers with unusual whitespaces which can cause possible http request smuggling. | ||||
CVE-2017-1000487 | 3 Codehaus-plexus, Debian, Redhat | 4 Plexus-utils, Debian Linux, Jboss Amq and 1 more | 2024-11-21 | 9.8 Critical |
Plexus-utils before 3.0.16 is vulnerable to command injection because it does not correctly process the contents of double quoted strings. | ||||
CVE-2016-8750 | 2 Apache, Redhat | 3 Karaf, Jboss Amq, Jboss Fuse | 2024-11-21 | N/A |
Apache Karaf prior to 4.0.8 used the LDAPLoginModule to authenticate users to a directory via LDAP. However, it did not encoding usernames properly and hence was vulnerable to LDAP injection attacks leading to a denial of service. | ||||
CVE-2016-8653 | 1 Redhat | 2 Jboss A-mq, Jboss Fuse | 2024-11-21 | N/A |
It was found that the JMX endpoint of Red Hat JBoss Fuse 6, and Red Hat A-MQ 6 deserializes the credentials passed to it. An attacker could use this flaw to launch a denial of service attack. | ||||
CVE-2016-8648 | 1 Redhat | 2 Jboss A-mq, Jboss Fuse | 2024-11-21 | N/A |
It was found that the Karaf container used by Red Hat JBoss Fuse 6.x, and Red Hat JBoss A-MQ 6.x, deserializes objects passed to MBeans via JMX operations. An attacker could use this flaw to execute remote code on the server as the user running the Java Virtual Machine if the target MBean contain deserialization gadgets in its classpath. | ||||
CVE-2016-6814 | 2 Apache, Redhat | 7 Groovy, Enterprise Linux, Enterprise Linux Server and 4 more | 2024-11-21 | N/A |
When an application with unsupported Codehaus versions of Groovy from 1.7.0 to 2.4.3, Apache Groovy 2.4.4 to 2.4.7 on classpath uses standard Java serialization mechanisms, e.g. to communicate between servers or to store local data, it was possible for an attacker to bake a special serialized object that will execute code directly when deserialized. All applications which rely on serialization and do not isolate the code which deserializes objects were subject to this vulnerability. | ||||
CVE-2016-5397 | 2 Apache, Redhat | 3 Thrift, Jboss Data Virtualization, Jboss Fuse | 2024-11-21 | N/A |
The Apache Thrift Go client library exposed the potential during code generation for command injection due to using an external formatting tool. Affected Apache Thrift 0.9.3 and older, Fixed in Apache Thrift 0.10.0. | ||||
CVE-2016-10750 | 2 Hazelcast, Redhat | 2 Hazelcast, Jboss Fuse | 2024-11-21 | N/A |
In Hazelcast before 3.11, the cluster join procedure is vulnerable to remote code execution via Java deserialization. If an attacker can reach a listening Hazelcast instance with a crafted JoinRequest, and vulnerable classes exist in the classpath, the attacker can run arbitrary code. | ||||
CVE-2016-1000352 | 2 Bouncycastle, Redhat | 4 Legion-of-the-bouncy-castle-java-crytography-api, Jboss Fuse, Satellite and 1 more | 2024-11-21 | N/A |
In the Bouncy Castle JCE Provider version 1.55 and earlier the ECIES implementation allowed the use of ECB mode. This mode is regarded as unsafe and support for it has been removed from the provider. | ||||
CVE-2016-1000346 | 3 Bouncycastle, Debian, Redhat | 5 Legion-of-the-bouncy-castle-java-crytography-api, Debian Linux, Jboss Fuse and 2 more | 2024-11-21 | N/A |
In the Bouncy Castle JCE Provider version 1.55 and earlier the other party DH public key is not fully validated. This can cause issues as invalid keys can be used to reveal details about the other party's private key where static Diffie-Hellman is in use. As of release 1.56 the key parameters are checked on agreement calculation. | ||||
CVE-2016-1000345 | 3 Bouncycastle, Debian, Redhat | 5 Legion-of-the-bouncy-castle-java-crytography-api, Debian Linux, Jboss Fuse and 2 more | 2024-11-21 | N/A |
In the Bouncy Castle JCE Provider version 1.55 and earlier the DHIES/ECIES CBC mode vulnerable to padding oracle attack. For BC 1.55 and older, in an environment where timings can be easily observed, it is possible with enough observations to identify when the decryption is failing due to padding. | ||||
CVE-2016-1000344 | 2 Bouncycastle, Redhat | 4 Legion-of-the-bouncy-castle-java-crytography-api, Jboss Fuse, Satellite and 1 more | 2024-11-21 | N/A |
In the Bouncy Castle JCE Provider version 1.55 and earlier the DHIES implementation allowed the use of ECB mode. This mode is regarded as unsafe and support for it has been removed from the provider. | ||||
CVE-2016-1000343 | 3 Bouncycastle, Debian, Redhat | 5 Legion-of-the-bouncy-castle-java-crytography-api, Debian Linux, Jboss Fuse and 2 more | 2024-11-21 | N/A |
In the Bouncy Castle JCE Provider version 1.55 and earlier the DSA key pair generator generates a weak private key if used with default values. If the JCA key pair generator is not explicitly initialised with DSA parameters, 1.55 and earlier generates a private value assuming a 1024 bit key size. In earlier releases this can be dealt with by explicitly passing parameters to the key pair generator. | ||||
CVE-2016-1000342 | 3 Bouncycastle, Debian, Redhat | 5 Legion-of-the-bouncy-castle-java-crytography-api, Debian Linux, Jboss Fuse and 2 more | 2024-11-21 | N/A |
In the Bouncy Castle JCE Provider version 1.55 and earlier ECDSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of 'invisible' data into a signed structure. | ||||
CVE-2016-1000341 | 3 Bouncycastle, Debian, Redhat | 5 Legion-of-the-bouncy-castle-java-crytography-api, Debian Linux, Jboss Fuse and 2 more | 2024-11-21 | N/A |
In the Bouncy Castle JCE Provider version 1.55 and earlier DSA signature generation is vulnerable to timing attack. Where timings can be closely observed for the generation of signatures, the lack of blinding in 1.55, or earlier, may allow an attacker to gain information about the signature's k value and ultimately the private value as well. | ||||
CVE-2016-1000340 | 2 Bouncycastle, Redhat | 4 Legion-of-the-bouncy-castle-java-crytography-api, Jboss Fuse, Satellite and 1 more | 2024-11-21 | N/A |
In the Bouncy Castle JCE Provider versions 1.51 to 1.55, a carry propagation bug was introduced in the implementation of squaring for several raw math classes have been fixed (org.bouncycastle.math.raw.Nat???). These classes are used by our custom elliptic curve implementations (org.bouncycastle.math.ec.custom.**), so there was the possibility of rare (in general usage) spurious calculations for elliptic curve scalar multiplications. Such errors would have been detected with high probability by the output validation for our scalar multipliers. | ||||
CVE-2016-1000339 | 3 Bouncycastle, Debian, Redhat | 5 Legion-of-the-bouncy-castle-java-crytography-api, Debian Linux, Jboss Fuse and 2 more | 2024-11-21 | N/A |
In the Bouncy Castle JCE Provider version 1.55 and earlier the primary engine class used for AES was AESFastEngine. Due to the highly table driven approach used in the algorithm it turns out that if the data channel on the CPU can be monitored the lookup table accesses are sufficient to leak information on the AES key being used. There was also a leak in AESEngine although it was substantially less. AESEngine has been modified to remove any signs of leakage (testing carried out on Intel X86-64) and is now the primary AES class for the BC JCE provider from 1.56. Use of AESFastEngine is now only recommended where otherwise deemed appropriate. | ||||
CVE-2016-1000338 | 4 Bouncycastle, Canonical, Netapp and 1 more | 6 Legion-of-the-bouncy-castle-java-crytography-api, Ubuntu Linux, 7-mode Transition Tool and 3 more | 2024-11-21 | 7.5 High |
In Bouncy Castle JCE Provider version 1.55 and earlier the DSA does not fully validate ASN.1 encoding of signature on verification. It is possible to inject extra elements in the sequence making up the signature and still have it validate, which in some cases may allow the introduction of 'invisible' data into a signed structure. |