A flaw was discovered in the way the Libraries component of OpenJDK processed X.509 certificates. Values of Object Identifiers (OIDs) were "interned", possibly allowing a malicious X.509 certificate to trigger excessive memory usage in a Java application processing such certificate.
An unspecified vulnerability in Java SE related to the Java SE Networking component could allow an unauthenticated attacker to cause a denial of service resulting in a low availability impact using unknown attack vectors.
A flaw was found in the way the GssKrb5Base class in the Security component of OpenJDK validated properties of SASL messages included in Kerberos GSSAPI, omitting required token checks. An remote attacker with ability to manipulate network traffic between server and client using Kerberos GSSAPI could possibly perform message modification that would not be detected during message decoding.
A flaw was found in the what the BeanContextSupport class in the Serialization component of OpenJDK handled exceptions during deserialization. A specially-crafted input could cause a Java application to use an excessive amount of resources when deserialized.
A flaw was found in the kernels implementation of the bluetooth HIDP (Human Interface Device Protocol). A local attacker with access permissions to the bluetooth device can issue an IOCTL which will trigger the dohidpsockioctl function in net/bluetooth/hidp/sock.c.c. This function can potentially leak potentially sensitive information from kernel stack memory via a HIDPCONNADD command, because a name field may not correctly NULL terminated.
Reference: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.15
Upstream commit: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a1616a5ac99ede5d605047a9012481ce7ff18b16 https://github.com/torvalds/linux/commit/a1616a5ac99ede5d605047a9012481ce7ff18b16
A memory disclosure flaw was found in the FileChannelImpl class in the Libraries component of OpenJDK. An untrusted Java application or applet could use this flaw leak limited amount of Java Virtual Machine memory possibly containing sensitive information, resulting in a partial bypass of Java sandbox restrictions.
It was discovered that the Security component of OpenJDK could incorrectly use unsigned manifest attribute entries when only properly signed entries were meant to be used. This could lead to bypass of protections provided by Jar signing. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.
An information leak flaw was found in the Networking component of OpenJDK. The HttpURLConnection class implementation could re-send HTTP headers containing sensitive data (such as Cookie or Authorization headers) to a different host when following HTTP redirects. This could lead to exposure of data to unintended HTTP hosts.
It was discovered that the Security component of OpenJDK did not correctly perform merging of multiple sections for the same file listed in the JAR archive file manifest. An attacker could possibly use this flaw to alter certain attributes specified in the manifest without changing archive signature.
Last updated 18 August 2025
It was discovered that the Security component of OpenJDK did not allow users to restrict the set of algorithms allowed for Jar integrity verification. This flaw could allow an attacker to modify content of the Jar file that used weak signing key or hash algorithm.
This problem was originally addressed as part of October 2016 CPU as CVE-2016-5542 (bug 1385723). In that update, the following changes were made:
- New security property jdk.jar.disabledAlgorithms was introduced, which can be used to restrict which algorithms can be used for jar verification.
- MD2 hash algorithm and RSA keys with less than 1024 bits were disabled by default.
At the same time, it was announced that the MD5 has algorithm was going to be disabled in the future updates. It was originally planned to get disabled as part of the January 2017 CPU, but the change was further postponed to the April 2017 CPU. Hence, MD5 is now becoming disabled by default.
The further details of the planned cryptography changes are available on the "Oracle JRE and JDK Cryptographic Roadmap" page:
https://www.java.com/en/jre-jdk-cryptoroadmap.html
It was discovered that the FTP client implementation in the Networking component of OpenJDK failed to correctly handle user inputs (e.g. usernames and passwords) containing newline characters. A remote attacker could possibly use this flaw to manipulate an FTP connection opened by a Java application if it could make it access a specially crafted FTP URL.
Blog posts were published that describe how to use this flaw to open ports on firewalls using active FTP connections:
http://blog.blindspotsecurity.com/2017/02/advisory-javapython-ftp-injections.html
and sending mails during XML parsing when use of XML external entities is allowed:
https://shiftordie.de/blog/2017/02/18/smtp-over-xxe/
It was discovered that the SMTP client implementation in the Networking component of OpenJDK failed to correctly handle sender and recipient addresses containing newline characters. A remote attacker could possibly use this flaw to manipulate an SMTP connection opened by a Java application if it could make it send an email to or from a specially crafted address.
It was discovered that the Invariance Weakness of the RC4 stream cipher could be used to recover plaintext from a TLS connection, when RC4 encryption is used.
"The Invariance Weakness is an L-shape key pattern in RC4 keys, which once it exists in an RC4 key, preserves part of the state permutation intact throughout the initialization process. This intact part includes the least significant bits of the permutation, when processed by the PRGA algorithm, determines the least significant bits of the allegedly pseudo-random output stream along a long prefix of the stream."
This can lead to significant leakage of plaintext bytes from the ciphertext.
External Reference:
http://www.imperva.com/docs/HIIAttackingSSLwhenusingRC4.pdf
Last updated 24 July 2024
Last updated 24 July 2024
Unspecified vulnerability in Oracle MySQL Server 5.5.35 and earlier and 5.6.15 and earlier allows remote authenticated users to affect availability via unknown vectors related to Replication.
Unspecified vulnerability Oracle the MySQL Server component 5.5.35 and earlier and 5.6.15 and earlier allows remote authenticated users to affect availability via unknown vectors related to Federated.
Unspecified vulnerability in Oracle MySQL Server 5.5.36 and earlier and 5.6.16 and earlier allows remote authenticated users to affect availability via unknown vectors related to Performance Schema.
Unspecified vulnerability in Oracle MySQL Server 5.5.36 and earlier and 5.6.16 and earlier allows remote attackers to affect availability via unknown vectors related to Options.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.72 and earlier, 5.5.34 and earlier, and 5.6.14 and earlier allows remote authenticated users to affect availability via unknown vectors related to Optimizer.
Unspecified vulnerability in the MySQL Server component in Oracle MySQL 5.1.71 and earlier, 5.5.33 and earlier, and 5.6.13 and earlier allows remote authenticated users to affect integrity via unknown vectors related to InnoDB.
Unspecified vulnerability in Oracle MySQL 5.1.68 and earlier, 5.5.30 and earlier, and 5.6.10 and earlier allows local users to affect confidentiality and integrity via unknown vectors related to Server Install.
Unspecified vulnerability in Oracle MySQL 5.1.67 and earlier, 5.5.29 and earlier, and 5.6.10 and earlier allows remote authenticated users to affect availability via unknown vectors related to Server Locking.
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 update 32 and earlier, 5 update 35 and earlier, and 1.4.237 and earlier allows local users to affect confidentiality via unknown vectors related to printing on Solaris or Linux.
Description of problem: On x86-64, a 32-bit process (TIFIA32) can switch to 64-bit mode with ljmp, and then use the "syscall" instruction to make a 64-bit system call. A 64-bit process make a 32-bit system call with int $0x80.
In both these cases, auditsyscallentry() will use the wrong system call number table and the wrong system call argument registers. This could be used to circumvent a syscall audit configuration that filters based on the syscall numbers or argument details.
References: http://scary.beasts.org/security/CESA-2009-001.html http://scary.beasts.org/security/CESA-2009-004.html https://bugzilla.redhat.com/showbug.cgi?id=487255 http://lkml.org/lkml/2009/2/27/451 summary http://lkml.org/lkml/2009/2/27/452 syscall-audit