A vulnerability was found in OpenSSL 1.0.2. When an application encounters a fatal protocol error and then calls SSLshutdown() twice, OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. This difference in behaviour can be detected by a remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Also the application must call SSLshutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). AEAD ciphersuites are not impacted. This issue does not impact OpenSSL 1.1.1 or 1.1.0.
Upstream bug: https://www.openssl.org/news/secadv/20190226.txt
Upstream Patch: https://github.com/openssl/openssl/commit/e9bbefbf0f24c57645e7ad6a5a71ae649d18ac8e
An attacker able to send and receive messages to an authoritative DNS server may be able to circumvent TSIG authentication of AXFR requests via a carefully constructed request packet. A server that relies solely on TSIG keys for protection with no other ACL protection could be manipulated into:
providing an AXFR of a zone to an unauthorized recipient accepting bogus Notify packets
An unauthorized AXFR (full zone transfer) permits an attacker to view the entire contents of a zone. Protection of zone contents is often a commercial or business requirement.
If accepted, a Notify sets the zone refresh interval to 'now'. If there is not already a refresh cycle in progress then named will initiate one by asking for the SOA RR from its list of masters. If there is already a refresh cycle in progress, then named will queue the new refresh request. If there is already a queued refresh request, the new Notify will be discarded. Bogus notifications can't be used to force a zone transfer from a malicious server, but could trigger a high rate of zone refresh cycles.
Workarounds:
The effects of this vulnerability can be mitigated by using Access Control Lists (ACLs) that require both address range validation and use of TSIG authentication in parallel. For information on how to configure this type of compound authentication control, please see:
https://kb.isc.org/article/AA-00723/0/Using-Access-Control-Lists-ACLs-with-both-addresses-and-keys.html.
(Note that this technique will not be effective against bogus Notify packets if an attacker is able to reach the target DNS server whilst using a spoofed sending address).
Upstream patch:
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=581c1526ab
An insufficient policy enforcement flaw was found in the CORS component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1026546
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An incorrect security ui flaw was found in the Omnibox component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1006012
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An inappropriate implementation flaw was found in the CORS component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1038036
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An incorrect security ui flaw was found in the sharing component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1027408
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An inappropriate implementation flaw was found in the Skia component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1035271
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An insufficient policy enforcement flaw was found in the extensions component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1030411
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An insufficient policy enforcement flaw was found in the Blink component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1035058
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An insufficient policy enforcement flaw was found in the Blink component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1014371
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
An insufficient validation of untrusted input flaw was found in the Blink component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1017871
External References:
https://chromereleases.googleblog.com/2020/02/stable-channel-update-for-desktop.html
It was discovered that the Kerberos implementation in the Security component of OpenJDK used RSA-MD5 checksum in Ticket Granting Service (TGS) requests even though MD5 algorithm is no longer considered safe for such use case. A remote attacker could possibly use this flaw to manipulate TGS requests.
A flaw was found in the URL class implementation in the Networking component of OpenJDK. An incorrect check to determine if a URLStreamHandler is builtin or not can lead to incorrect URL normalization in certain cases.
A use-after-free vulnerability was discovered in the pngimagefree function in the libpng library. This could lead to denial of service or a potentially exploitable crash when a malformed image is processed.
In PolicyKit (aka polkit) 0.115, the "start time" protection mechanism can be bypassed because fork() is not atomic, and therefore authorization decisions are improperly cached. This is related to lack of uid checking in polkitbackend/polkitbackendinteractiveauthority.c.
An input validation flaw was found in the URL class implementation in the Networking component of OpenJDK. A URL class instance could have been created for a URL string containing invalid characters not permitted in URLs.
It was discovered that the implementation of the Collections class in the Utilities component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.
It was discovered that the implementation of the Throwable class in the Utilities component of OpenJDK did not sufficiently validate serial stream before deserializing suppressed exceptions. A specially-crafted input could cause a Java application to construct inconsistent object and possibly use an excessive amount of system resources when deserialized.
An out of bounds read flaw was found in the SQLite component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1025471
External References:
https://chromereleases.googleblog.com/2019/12/stable-channel-update-for-desktop.html
An insufficient data validation flaw was found in the SQLite component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1025464
External References:
https://chromereleases.googleblog.com/2019/12/stable-channel-update-for-desktop.html
An uninitialized use flaw was found in the SQLite component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1025465
External References:
https://chromereleases.googleblog.com/2019/12/stable-channel-update-for-desktop.html
An out of bounds read flaw was found in the SQLite component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1025470
External References:
https://chromereleases.googleblog.com/2019/12/stable-channel-update-for-desktop.html
Last updated 25 August 2025
Cross-site scripting (XSS) vulnerability in the web UI in Mailman before 2.1.26 allows remote attackers to inject arbitrary web script or HTML via a user-options URL.
Last updated 25 August 2025
An information leakage flaw is found in the way Linux kernel saves and restores Floating Point Unit(FPU) state during task switch. There are two ways, one is to save & restore FPU state during task context switch. And second is to defer FPU state save & restore until an FP instruction is invoked by the current task. First is called as "Eager FPU Restore" and second is known as "Lazy FPU Restore" scheme.
Linux kernel which follows the "Lazy FPU Restore" scheme is vulnerable to the FPU state information leakage issue. An unprivileged local attacker could use this flaw to read FPU state bits by conducting targeted cache side-channel attacks, similar to Meltdown attack disclosed earlier this year.
Upstream fix: ------------- -> https://git.kernel.org/linus//58122bf1d856a4ea9581d62a07c557d997d46a19
References: ----------- -> http://www.openwall.com/lists/oss-security/2018/06/13/7
An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of Load & Store instructions (a commonly used performance optimization).
It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory read from address to which a recent memory write has occurred may see an older value and subsequently cause an update into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire).
As a result, an unprivileged attacker could use this flaw to read privileged memory by conducting targeted cache side-channel attacks.
Last updated 25 August 2025
In libpng 1.6.34, a wrong calculation of rowfactor in the pngcheckchunklength function (pngrutil.c) may trigger an integer overflow and resultant divide-by-zero while processing a crafted PNG file, leading to a denial of service.
XSS Auditor in Google Chrome prior to 57.0.2987.98 for Mac, Windows, and Linux and 57.0.2987.108 for Android allowed detection of a blocked iframe load, which allowed a remote attacker to brute force JavaScript variables via a crafted HTML page.