CVSS: 4.3EPSS: 0%CPEs: 26EXPL: 0CVE-2020-14779 – OpenJDK: High memory usage during deserialization of Proxy class with many interfaces (Serialization, 8236862)
https://notcve.org/view.php?id=CVE-2020-14779
Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Serialization). Supported versions that are affected are Java SE: 7u271, 8u261, 11.0.8 and 15; Java SE Embedded: 8u261. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: Applies to client and server deployment of Java. • http://lists.opensuse.org/opensuse-security-announce/2020-11/msg00041.html https://lists.debian.org/debian-lts-announce/2020/10/msg00031.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/N6CJCO52DHIQJHLPF6HMTC5Z2VKFRQMY https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/OMJMTXFJRONFT72YAEQNRFKYZZU4W3HD https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XKRGVMZT3EUUWKUA6DBT56FT3UOKPHQ2 https://lists.fedoraproject.or • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 5.9EPSS: 1%CPEs: 180EXPL: 0CVE-2019-1559 – 0-byte record padding oracle
https://notcve.org/view.php?id=CVE-2019-1559
If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then 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. If the application then behaves differently based on that in a way that is detectable to the 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. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). • http://lists.opensuse.org/opensuse-security-announce/2019-03/msg00041.html http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00019.html http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00046.html http://lists.opensuse.org/opensuse-security-announce/2019-04/msg00047.html http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00049.html http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00080.html http://www.securityfocus.com/bid/107174 https://access. • CWE-203: Observable Discrepancy CWE-325: Missing Cryptographic Step •
CVSS: 5.3EPSS: 0%CPEs: 35EXPL: 0CVE-2018-17189 – httpd: mod_http2: DoS via slow, unneeded request bodies
https://notcve.org/view.php?id=CVE-2018-17189
In Apache HTTP server versions 2.4.37 and prior, by sending request bodies in a slow loris way to plain resources, the h2 stream for that request unnecessarily occupied a server thread cleaning up that incoming data. This affects only HTTP/2 (mod_http2) connections. En Apache HTTP Server, en sus versiones 2.4.37 y anteriores, mediante el envío de cuerpos de respuesta mediante la técnica del "slow loris" a recursos planos, la transmisión h2 para esa petición ocupó de forma innecesaria un hilo de servidor que limpiaba tales datos entrantes. Esto afecta solo a las conexiones HTTP/2 (mod_http2). • http://www.securityfocus.com/bid/106685 https://access.redhat.com/errata/RHSA-2019:3932 https://access.redhat.com/errata/RHSA-2019:3933 https://access.redhat.com/errata/RHSA-2019:3935 https://access.redhat.com/errata/RHSA-2019:4126 https://httpd.apache.org/security/vulnerabilities_24.html https://lists.apache.org/thread.html/56c2e7cc9deb1c12a843d0dc251ea7fd3e7e80293cde02fcd65286ba%40%3Ccvs.httpd.apache.org%3E https://lists.apache.org/thread.html/84a3714f0878781f6ed84473d1a503d2cc382277e100450209231830%40%3Ccvs.httpd.apache • CWE-400: Uncontrolled Resource Consumption •
CVSS: 7.5EPSS: 0%CPEs: 10EXPL: 0CVE-2018-17199 – httpd: mod_session_cookie does not respect expiry time
https://notcve.org/view.php?id=CVE-2018-17199
In Apache HTTP Server 2.4 release 2.4.37 and prior, mod_session checks the session expiry time before decoding the session. This causes session expiry time to be ignored for mod_session_cookie sessions since the expiry time is loaded when the session is decoded. En Apache HTTP Server 2.4, en sus distribuciones 2.4.37 y anteriores, mod_session comprueba el tiempo de caducidad de la sesión antes de descodificarla. Esto provoca que se ignore el tiempo de caducidad de la sesión para sesiones mod_session_cookie, debido a que el tiempo de caducidad se carga cuando la sesión está descodificada. • http://www.securityfocus.com/bid/106742 https://access.redhat.com/errata/RHSA-2019:3932 https://access.redhat.com/errata/RHSA-2019:3933 https://access.redhat.com/errata/RHSA-2019:3935 https://access.redhat.com/errata/RHSA-2019:4126 https://httpd.apache.org/security/vulnerabilities_24.html https://lists.apache.org/thread.html/56c2e7cc9deb1c12a843d0dc251ea7fd3e7e80293cde02fcd65286ba%40%3Ccvs.httpd.apache.org%3E https://lists.apache.org/thread.html/84a3714f0878781f6ed84473d1a503d2cc382277e100450209231830%40%3Ccvs.httpd.apache • CWE-384: Session Fixation CWE-613: Insufficient Session Expiration •
CVSS: 9.8EPSS: 1%CPEs: 29EXPL: 0CVE-2017-7658 – jetty: Incorrect header handling
https://notcve.org/view.php?id=CVE-2017-7658
In Eclipse Jetty Server, versions 9.2.x and older, 9.3.x (all non HTTP/1.x configurations), and 9.4.x (all HTTP/1.x configurations), when presented with two content-lengths headers, Jetty ignored the second. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decided on the shorter length, but still passed on the longer body, then body content could be interpreted by Jetty as a pipelined request. If the intermediary was imposing authorization, the fake pipelined request would bypass that authorization. En Eclipse Jetty Server, en versiones 9.2.x y anteriores, versiones 9.3.x (todas las configuraciones que no sean HTTP/1.x) y versiones 9.4.x (todas las configuraciones HTTP/1.x), cuando se presentan con dos cabeceras content-lengths, Jetty ignora la segunda. • http://www.securityfocus.com/bid/106566 http://www.securitytracker.com/id/1041194 https://bugs.eclipse.org/bugs/show_bug.cgi?id=535669 https://lists.apache.org/thread.html/053d9ce4d579b02203db18545fee5e33f35f2932885459b74d1e4272%40%3Cissues.activemq.apache.org%3E https://lists.apache.org/thread.html/708d94141126eac03011144a971a6411fcac16d9c248d1d535a39451%40%3Csolr-user.lucene.apache.org%3E https://lists.apache.org/thread.html/9317fd092b257a0815434b116a8af8daea6e920b6673f4fd5583d5fe%40%3Ccommits.druid.apache.org%3E https://lists.apache.org/thread& • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •