Show filters
366 Total Results
Displaying 11-20 of 366
Sort by:
Attacker Value
High
CVE-2014-0160 (AKA: Heartbleed)
Disclosure Date: April 07, 2014 (last updated July 03, 2024)
The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug.
0
Attacker Value
Unknown
CVE-2020-11022
Disclosure Date: April 29, 2020 (last updated February 21, 2025)
In jQuery versions greater than or equal to 1.2 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.
4
Attacker Value
Unknown
CVE-2016-2775
Disclosure Date: July 19, 2016 (last updated November 08, 2023)
ISC BIND 9.x before 9.9.9-P2, 9.10.x before 9.10.4-P2, and 9.11.x before 9.11.0b2, when lwresd or the named lwres option is enabled, allows remote attackers to cause a denial of service (daemon crash) via a long request that uses the lightweight resolver protocol.
1
Attacker Value
Unknown
CVE-2017-3167
Disclosure Date: June 20, 2017 (last updated November 08, 2023)
In Apache httpd 2.2.x before 2.2.33 and 2.4.x before 2.4.26, use of the ap_get_basic_auth_pw() by third-party modules outside of the authentication phase may lead to authentication requirements being bypassed.
1
Attacker Value
Unknown
CVE-2021-4104
Disclosure Date: December 14, 2021 (last updated February 23, 2025)
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.
1
Attacker Value
Unknown
CVE-2015-1931
Disclosure Date: September 29, 2022 (last updated October 08, 2023)
IBM Java Security Components in IBM SDK, Java Technology Edition 8 before SR1 FP10, 7 R1 before SR3 FP10, 7 before SR9 FP10, 6 R1 before SR8 FP7, 6 before SR16 FP7, and 5.0 before SR16 FP13 stores plaintext information in memory dumps, which allows local users to obtain sensitive information by reading a file.
0
Attacker Value
Unknown
CVE-2022-0330
Disclosure Date: March 25, 2022 (last updated October 07, 2023)
A random memory access flaw was found in the Linux kernel's GPU i915 kernel driver functionality in the way a user may run malicious code on the GPU. This flaw allows a local user to crash the system or escalate their privileges on the system.
0
Attacker Value
Unknown
CVE-2021-45105
Disclosure Date: December 18, 2021 (last updated February 23, 2025)
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0, 2.12.3, and 2.3.1.
0
Attacker Value
Unknown
CVE-2021-29425
Disclosure Date: April 13, 2021 (last updated February 22, 2025)
In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "limited" path traversal), if the calling code would use the result to construct a path value.
0
Attacker Value
Unknown
CVE-2021-21348
Disclosure Date: March 23, 2021 (last updated February 22, 2025)
XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability which may allow a remote attacker to occupy a thread that consumes maximum CPU time and will never return. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16.
0