WaratekVRT Sign in
Reset
More filters (2)
Columns
Protection: None✕Vendor eclipse✕
Overview 130 matches · 0 protected · 3 exploited · 1 CISA KEV · 4 public PoC · 6 EPSS ≥ 0.5
130matches 0protected0.0% 3exploited2.3% 1CISA KEV0.8% 4public PoC3.1% 6EPSS ≥ 0.54.6%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 5 3.8% No exploit published 125 96.2%
Critical 18 13.8% High 57 43.8% Medium 50 38.5% Low 5 3.8% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 130 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 3 2.3% Working exploit published 2 1.5% Proof of concept only 9 6.9% Forecast only 2 1.5% No public exploit 114 87.7%
split by peak 34 / year
No exploit published: 125Mitigation candidate: 5 Low: 5Medium: 50High: 57Critical: 18 not blocked: 130 No public exploit: 114Forecast only: 2Proof of concept only: 9Working exploit published: 2Exploited: 3
20161 Mitigation candidate1 High1 not blocked1 Working exploit published1 20172 Mitigation candidate1 No exploit published1 Critical1 High1 not blocked2 Exploited1 No public exploit1 20188 No exploit published8 Critical2 High3 Medium3 not blocked8 No public exploit8 201919 No exploit published19 Critical5 High9 Medium5 not blocked19 No public exploit19 20206 Mitigation candidate1 No exploit published5 Critical2 High2 Medium2 not blocked6 Working exploit published1 No public exploit5 20219 Mitigation candidate1 No exploit published8 Critical1 High2 Medium4 Low2 not blocked9 Exploited1 Forecast only2 No public exploit6 202210 No exploit published10 High5 Medium4 Low1 not blocked10 No public exploit10 202314 Mitigation candidate1 No exploit published13 Critical2 High5 Medium6 Low1 not blocked14 Exploited1 No public exploit13 202413 No exploit published13 High4 Medium9 not blocked13 Proof of concept only2 No public exploit11 202514 No exploit published14 Critical1 High5 Medium7 Low1 not blocked14 Proof of concept only2 No public exploit12 202634 No exploit published34 Critical4 High20 Medium10 not blocked34 Proof of concept only5 No public exploit29
20162017201820192020202120222023202420252026
130 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed. ‹ prev page 2 of 2 next ›
CVE Severity Published▾ Status Exploitation Description
CVE-2019-17632 Medium 2019-11-25 No exploit published No public exploit In Eclipse Jetty versions 9.4.21.v20190926, 9.4.22.v20191022, and 9.4.23.v20191118, the generation of default unhandled Error response content (in text/html and text/json Content-Type) does not escape Exception messages in stacktraces included in error output.
CVE-2009-5046 Medium 2019-11-06 No exploit published No public exploit JSP Dump and Session Dump Servlet XSS in jetty before 6.1.22.
CVE-2009-5045 High 2019-11-06 No exploit published No public exploit Dump Servlet information leak in jetty before 6.1.22.
CVE-2019-17631 Critical 2019-10-17 No exploit published No public exploit From Eclipse OpenJ9 0.15 to 0.16, access to diagnostic operations such as causing a GC or creating a diagnostic file are permitted without any privilege checks.
CVE-2019-11777 High 2019-09-11 No exploit published No public exploit In the Eclipse Paho Java client library version 1.2.0, when connecting to an MQTT server using TLS and setting a host name verifier, the result of that verification is not checked. This could allow one MQTT server to impersonate another and provide the client library with incorrect information.
CVE-2019-11775 High 2019-07-30 No exploit published No public exploit All builds of Eclipse OpenJ9 prior to 0.15 contain a bug where the loop versioner may fail to privatize a value that is pulled out of the loop by versioning - for example if there is a condition that is moved out of the loop that reads a field we may not privatize the value of that field in the modified copy of the loop allowing the test to see one value of the field and subsequently the loop to see a modified field value without retesting the condition moved out of the loop. This can lead to a variety of different issues but read out of array bounds is one major consequence of these problems.
CVE-2019-11772 Critical 2019-07-17 No exploit published No public exploit In Eclipse OpenJ9 prior to 0.15, the String.getBytes(int, int, byte[], int) method does not verify that the provided byte array is non-null nor that the provided index is in bounds when compiled by the JIT. This allows arbitrary writes to any 32-bit address or beyond the end of a byte array within Java code run under a SecurityManager.
CVE-2019-11771 High 2019-07-17 No exploit published No public exploit AIX builds of Eclipse OpenJ9 before 0.15.0 contain unused RPATHs which may facilitate code injection and privilege elevation by local users.
CVE-2019-10249 High 2019-05-06 No exploit published No public exploit All Xtext & Xtend versions prior to 2.18.0 were built using HTTP instead of HTTPS file transfer and thus the built artifacts may have been compromised.
CVE-2019-10248 High 2019-04-22 No exploit published No public exploit Eclipse Vorto versions prior to 0.11 resolved Maven build artifacts for the Xtext project over HTTP instead of HTTPS. Any of these dependent artifacts could have been maliciously compromised by a MITM attack. Hence produced build artifacts of Vorto might be infected.
CVE-2019-10247 Medium 2019-04-22 No exploit published No public exploit In Eclipse Jetty version 7.x, 8.x, 9.2.27 and older, 9.3.26 and older, and 9.4.16 and older, the server running on any OS and Jetty version combination will reveal the configured fully qualified directory base resource location on the output of the 404 error for not finding a Context that matches the requested path. The default server behavior on jetty-distribution and jetty-home will include at the end of the Handler tree a DefaultHandler, which is responsible for reporting this 404 error, it presents the various configured contexts as HTML for users to click through to. This produced HTML includes output that contains the configured fully qualified directory base resource location for each context.
CVE-2019-10246 Medium 2019-04-22 No exploit published No public exploit In Eclipse Jetty version 9.2.27, 9.3.26, and 9.4.16, the server running on Windows is vulnerable to exposure of the fully qualified Base Resource directory name on Windows to a remote client when it is configured for showing a Listing of directory contents. This information reveal is restricted to only the content in the configured base resource directories.
CVE-2019-10241 Medium 2019-04-22 No exploit published No public exploit In Eclipse Jetty version 9.2.26 and older, 9.3.25 and older, and 9.4.15 and older, the server is vulnerable to XSS conditions if a remote client USES a specially formatted URL against the DefaultServlet or ResourceHandler that is configured for showing a Listing of directory contents.
CVE-2019-10245 High 2019-04-19 No exploit published No public exploit In Eclipse OpenJ9 prior to the 0.14.0 release, the Java bytecode verifier incorrectly allows a method to execute past the end of bytecode array causing crashes. Eclipse OpenJ9 v0.14.0 correctly detects this case and rejects the attempted class load.
CVE-2019-10240 High 2019-04-03 No exploit published No public exploit Eclipse hawkBit versions prior to 0.3.0M2 resolved Maven build artifacts for the Vaadin based UI over HTTP instead of HTTPS. Any of these dependent artifacts could have been maliciously compromised by a MITM attack. Hence produced build artifacts of hawkBit might be infected.
CVE-2018-12545 High 2019-03-27 No exploit published No public exploit In Eclipse Jetty version 9.3.x and 9.4.x, the server is vulnerable to Denial of Service conditions if a remote client sends either large SETTINGs frames container containing many settings, or many small SETTINGs frames. The vulnerability is due to the additional CPU and memory allocations required to handle changed settings.
CVE-2018-12549 Critical 2019-02-11 No exploit published No public exploit In Eclipse OpenJ9 version 0.11.0, the OpenJ9 JIT compiler may incorrectly omit a null check on the receiver object of an Unsafe call when accelerating it.
CVE-2018-12547 Critical 2019-02-11 No exploit published No public exploit In Eclipse OpenJ9, prior to the 0.12.0 release, the jio_snprintf() and jio_vsnprintf() native methods ignored the length parameter. This affects existing APIs that called the functions to exceed the allocated buffer. This functions were not directly callable by non-native user code.
CVE-2018-12548 Critical 2019-01-31 No exploit published No public exploit In OpenJDK + Eclipse OpenJ9 version 0.11.0 builds, the public jdk.crypto.jniprovider.NativeCrypto class contains public static natives which accept pointer values that are dereferenced in the native code.
CVE-2018-12541 Medium 2018-10-10 No exploit published No public exploit In version from 3.0.0 to 3.5.3 of Eclipse Vert.x, the WebSocket HTTP upgrade implementation buffers the full http request before doing the handshake, holding the entire request body in memory. There should be a reasonnable limit (8192 bytes) above which the WebSocket gets an HTTP response with the 413 status code and the connection gets closed.
CVE-2018-12537 Medium 2018-08-14 No exploit published No public exploit In Eclipse Vert.x version 3.0 to 3.5.1, the HttpServer response headers and HttpClient request headers do not filter carriage return and line feed characters from the header value. This allow unfiltered values to inject a new header in the client request or server response.
CVE-2018-12540 High 2018-07-12 No exploit published No public exploit In version from 3.0.0 to 3.5.2 of Eclipse Vert.x, the CSRFHandler do not assert that the XSRF Cookie matches the returned XSRF header/form parameter. This allows replay attacks with previously issued tokens which are not expired yet.
CVE-2018-12536 Medium 2018-06-27 No exploit published No public exploit In Eclipse Jetty Server, all 9.x versions, on webapps deployed using default Error Handling, when an intentionally bad query arrives that doesn't match a dynamic url-pattern, and is eventually handled by the DefaultServlet's static file serving, the bad characters can trigger a java.nio.file.InvalidPathException which includes the full path to the base resource directory that the DefaultServlet and/or webapp is using. If this InvalidPathException is then handled by the default Error Handler, the InvalidPathException message is included in the error response, revealing the full server path to the requesting system.
CVE-2017-7658 Critical 2018-06-26 No exploit published No public exploit 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.
CVE-2017-7657 Critical 2018-06-26 No exploit published No public exploit In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request.
CVE-2017-7656 High 2018-06-26 No exploit published No public exploit In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), HTTP/0.9 is handled poorly. An HTTP/1 style request line (i.e. method space URI space version) that declares a version of HTTP/0.9 was accepted and treated as a 0.9 request. If deployed behind an intermediary that also accepted and passed through the 0.9 version (but did not act on it), then the response sent could be interpreted by the intermediary as HTTP/1 headers. This could be used to poison the cache if the server allowed the origin client to generate arbitrary content in the response.
CVE-2018-12538 High 2018-06-22 No exploit published No public exploit In Eclipse Jetty versions 9.4.0 through 9.4.8, when using the optional Jetty provided FileSessionDataStore for persistent storage of HttpSession details, it is possible for a malicious user to access/hijack other HttpSessions and even delete unmatched HttpSessions present in the FileSystem's storage for the FileSessionDataStore.
CVE-2017-9735 High 2017-06-16 No exploit published No public exploit Jetty through 9.4.x is prone to a timing channel in util/security/Password.java, which makes it easier for remote attackers to obtain access by observing elapsed times before rejection of incorrect passwords.
CVE-2016-4800 Critical 2017-04-13 Mitigation candidate Exploited The path normalization mechanism in PathResource class in Eclipse Jetty 9.3.x before 9.3.9 on Windows allows remote attackers to bypass protected resource restrictions and other security constraints via a URL with certain escaped characters, related to backslashes.
CVE-2015-2080 High 2016-10-07 Mitigation candidate Working exploit published The exception handling code in Eclipse Jetty before 9.2.9.v20150224 allows remote attackers to obtain sensitive information from process memory via illegal characters in an HTTP header, aka JetLeak.
‹ prev page 2 of 2 next ›