Where
AND
-Infinity
0
Severity
2.6
AV:N/AC:H/Au:N/C:N/I:P/A:N

It was discovered that the CipherInputStream class implementation did not properly handle certain exceptions. This issue could possibly allow attacker to affect integrity of the encrypted stream handled using this class.

1 / 2
Source: Red Hat
First published (updated )
Severity
5
AV:N/AC:L/Au:N/C:P/I:N/A:N

It was discovered that the StAX XML parser in the JAXP (Java API for XML Processing) component of OpenJDK failed to properly honor setting indicating (defined using isSupportingExternalEntities / ISSUPPORTINGEXTERNALENTITIES property) whether external XML entities should be processed. External parameter entities were processed even when the StAX parser was configured to not process external entities. An attacker able to provide a specially-crafted XML file to an application using StAX parser could use this flaw to perform XML eXternal Entity (XXE) attack.

1 / 2
Source: Red Hat
First published (updated )
Severity
4.3
AV:N/AC:M/Au:N/C:N/I:P/A:N

It was discovered that DatagramSocket implementation in OpenJDK did not perform any packet source address checks for packets received on connected socket. This could cause an application using DatagramSocket to read a packet from the socket that originates from a different source to the one to which the socket was connected. This problem is caused by BSD socket API oddity, which returns packets form different source if they were queued before socket was connected.

This issue can make it easier to perform IP spoofing attacks, as it may allow packets to be processed by an application without packets actually having spoofed source address. It can also lead to limited security manager restrictions bypass.

http://docs.oracle.com/javase/7/docs/api/java/net/DatagramSocket.html

Acknowledgement:

This issue was discovered by Florian Weimer of Red Hat Product Security.

1 / 2
Source: Red Hat
First published (updated )
Severity
4
AV:N/AC:H/Au:N/C:N/I:P/A:P

It was discovered that the TLS/SSL implementation in the JSSE component of OpenJDK was vulnerable to the Triple Handshake attack. An insufficient check of server's identity during the renegotiation following session resumption could allow a malicious server to manipulate clients authenticated session with a different server if client certificate authentication was used.

Further details of the attacks are described on:

https://secure-resumption.com/

1 / 2
Source: Red Hat
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203