Filtered by vendor Eclipse
Subscribe
Total
170 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2021-28167 | 1 Eclipse | 1 Openj9 | 2024-06-21 | 6.4 MEDIUM | 6.5 MEDIUM |
| In Eclipse Openj9 to version 0.25.0, usage of the jdk.internal.reflect.ConstantPool API causes the JVM in some cases to pre-resolve certain constant pool entries. This allows a user to call static methods or access static members without running the class initialization method, and may allow a user to observe uninitialized values. | |||||
| CVE-2023-6194 | 1 Eclipse | 1 Memory Analyzer | 2024-02-28 | N/A | 7.1 HIGH |
| In Eclipse Memory Analyzer versions 0.7 to 1.14.0, report definition XML files are not filtered to prohibit document type definition (DTD) references to external entities. This means that if a user chooses to use a malicious report definition XML file containing an external entity reference to generate a report then Eclipse Memory Analyzer may access external files or URLs defined via a DTD in the report definition. | |||||
| CVE-2023-5676 | 1 Eclipse | 1 Openj9 | 2024-02-28 | N/A | 5.9 MEDIUM |
| In Eclipse OpenJ9 before version 0.41.0, the JVM can be forced into an infinite busy hang on a spinlock or a segmentation fault if a shutdown signal (SIGTERM, SIGINT or SIGHUP) is received before the JVM has finished initializing. | |||||
| CVE-2023-4218 | 1 Eclipse | 3 Eclipse Ide, Org.eclipse.core.runtime, Pde | 2024-02-28 | N/A | 5.0 MEDIUM |
| In Eclipse IDE versions < 2023-09 (4.29) some files with xml content are parsed vulnerable against all sorts of XXE attacks. The user just needs to open any evil project or update an open project with a vulnerable file (for example for review a foreign repository or patch). | |||||
| CVE-2023-36479 | 2 Debian, Eclipse | 2 Debian Linux, Jetty | 2024-02-28 | N/A | 4.3 MEDIUM |
| Eclipse Jetty Canonical Repository is the canonical repository for the Jetty project. Users of the CgiServlet with a very specific command structure may have the wrong command executed. If a user sends a request to a org.eclipse.jetty.servlets.CGI Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. This issue was patched in version 9.4.52, 10.0.16, 11.0.16 and 12.0.0-beta2. | |||||
| CVE-2023-41900 | 2 Debian, Eclipse | 2 Debian Linux, Jetty | 2024-02-28 | N/A | 4.3 MEDIUM |
| Jetty is a Java based web server and servlet engine. Versions 9.4.21 through 9.4.51, 10.0.15, and 11.0.15 are vulnerable to weak authentication. If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. This impacts usages of the jetty-openid which have configured a nested `LoginService` and where that `LoginService` will is capable of rejecting previously authenticated users. Versions 9.4.52, 10.0.16, and 11.0.16 have a patch for this issue. | |||||
| CVE-2023-40167 | 2 Debian, Eclipse | 2 Debian Linux, Jetty | 2024-02-28 | N/A | 5.3 MEDIUM |
| Jetty is a Java based web server and servlet engine. Prior to versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1, Jetty accepts the `+` character proceeding the content-length value in a HTTP/1 header field. This is more permissive than allowed by the RFC and other servers routinely reject such requests with 400 responses. There is no known exploit scenario, but it is conceivable that request smuggling could result if jetty is used in combination with a server that does not close the connection after sending such a 400 response. Versions 9.4.52, 10.0.16, 11.0.16, and 12.0.1 contain a patch for this issue. There is no workaround as there is no known exploit scenario. | |||||
| CVE-2023-4043 | 1 Eclipse | 1 Parsson | 2024-02-28 | N/A | 7.5 HIGH |
| In Eclipse Parsson before versions 1.1.4 and 1.0.5, Parsing JSON from untrusted sources can lead malicious actors to exploit the fact that the built-in support for parsing numbers with large scale in Java has a number of edge cases where the input text of a number can lead to much larger processing time than one would expect. To mitigate the risk, parsson put in place a size limit for the numbers as well as their scale. | |||||
| CVE-2023-41034 | 1 Eclipse | 1 Leshan | 2024-02-28 | N/A | 9.8 CRITICAL |
| Eclipse Leshan is a device management server and client Java implementation. In affected versions DDFFileParser` and `DefaultDDFFileValidator` (and so `ObjectLoader`) are vulnerable to `XXE Attacks`. A DDF file is a LWM2M format used to store LWM2M object description. Leshan users are impacted only if they parse untrusted DDF files (e.g. if they let external users provide their own model), in that case they MUST upgrade to fixed version. If you parse only trusted DDF file and validate only with trusted xml schema, upgrading is not mandatory. This issue has been fixed in versions 1.5.0 and 2.0.0-M13. Users are advised to upgrade. There are no known workarounds for this vulnerability. | |||||
| CVE-2023-3592 | 1 Eclipse | 1 Mosquitto | 2024-02-28 | N/A | 7.5 HIGH |
| In Mosquitto before 2.0.16, a memory leak occurs when clients send v5 CONNECT packets with a will message that contains invalid property types. | |||||
| CVE-2023-5632 | 1 Eclipse | 1 Mosquitto | 2024-02-28 | N/A | 7.5 HIGH |
| In Eclipse Mosquito before and including 2.0.5, establishing a connection to the mosquitto server without sending data causes the EPOLLOUT event to be added, which results excessive CPU consumption. This could be used by a malicious actor to perform denial of service type attack. This issue is fixed in 2.0.6 | |||||
| CVE-2023-5763 | 1 Eclipse | 1 Glassfish | 2024-02-28 | N/A | 9.8 CRITICAL |
| In Eclipse Glassfish 5 or 6, running with old versions of JDK (lower than 6u211, or < 7u201, or < 8u191), allows remote attackers to load malicious code on the server via access to insecure ORB listeners. | |||||
| CVE-2023-28366 | 1 Eclipse | 1 Mosquitto | 2024-02-28 | N/A | 7.5 HIGH |
| The broker in Eclipse Mosquitto 1.3.2 through 2.x before 2.0.16 has a memory leak that can be abused remotely when a client sends many QoS 2 messages with duplicate message IDs, and fails to respond to PUBREC commands. This occurs because of mishandling of EAGAIN from the libc send function. | |||||
| CVE-2023-0809 | 1 Eclipse | 1 Mosquitto | 2024-02-28 | N/A | 5.3 MEDIUM |
| In Mosquitto before 2.0.16, excessive memory is allocated based on malicious initial packets that are not CONNECT packets. | |||||
| CVE-2023-4760 | 1 Eclipse | 1 Remote Application Platform | 2024-02-28 | N/A | 9.8 CRITICAL |
| In Eclipse RAP versions from 3.0.0 up to and including 3.25.0, Remote Code Execution is possible on Windows when using the FileUpload component. The reason for this is a not completely secure extraction of the file name in the FileUploadProcessor.stripFileName(String name) method. As soon as this finds a / in the path, everything before it is removed, but potentially \ (backslashes) coming further back are kept. For example, a file name such as /..\..\webapps\shell.war can be used to upload a file to a Tomcat server under Windows, which is then saved as ..\..\webapps\shell.war in its webapps directory and can then be executed. | |||||
| CVE-2023-26048 | 1 Eclipse | 1 Jetty | 2024-02-28 | N/A | 5.3 MEDIUM |
| Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory). | |||||
| CVE-2023-26049 | 3 Debian, Eclipse, Netapp | 6 Debian Linux, Jetty, Active Iq Unified Manager and 3 more | 2024-02-28 | N/A | 5.3 MEDIUM |
| Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue. | |||||
| CVE-2023-32081 | 1 Eclipse | 1 Vert.x Stomp | 2024-02-28 | N/A | 6.5 MEDIUM |
| Vert.x STOMP is a vert.x implementation of the STOMP specification that provides a STOMP server and client. From versions 3.1.0 until 3.9.16 and 4.0.0 until 4.4.2, a Vert.x STOMP server processes client STOMP frames without checking that the client send an initial CONNECT frame replied with a successful CONNECTED frame. The client can subscribe to a destination or publish message without prior authentication. Any Vert.x STOMP server configured with an authentication handler is impacted. The issue is patched in Vert.x 3.9.16 and 4.4.2. There are no trivial workarounds. | |||||
| CVE-2022-2712 | 1 Eclipse | 1 Glassfish | 2024-02-28 | N/A | 7.5 HIGH |
| In Eclipse GlassFish versions 5.1.0 to 6.2.5, there is a vulnerability in relative path traversal because it does not filter request path starting with './'. Successful exploitation could allow an remote unauthenticated attacker to access critical data, such as configuration files and deployed application source code. | |||||
| CVE-2023-24815 | 1 Eclipse | 1 Vert.x-web | 2024-02-28 | N/A | 5.3 MEDIUM |
| Vert.x-Web is a set of building blocks for building web applications in the java programming language. When running vertx web applications that serve files using `StaticHandler` on Windows Operating Systems and Windows File Systems, if the mount point is a wildcard (`*`) then an attacker can exfiltrate any class path resource. When computing the relative path to locate the resource, in case of wildcards, the code: `return "/" + rest;` from `Utils.java` returns the user input (without validation) as the segment to lookup. Even though checks are performed to avoid escaping the sandbox, given that the input was not sanitized `\` are not properly handled and an attacker can build a path that is valid within the classpath. This issue only affects users deploying in windows environments and upgrading is the advised remediation path. There are no known workarounds for this vulnerability. | |||||