Filtered by vendor Eclipse
Subscriptions
Total
166 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2018-12543 | 1 Eclipse | 1 Mosquitto | 2024-08-05 | N/A |
| In Eclipse Mosquitto versions 1.5 to 1.5.2 inclusive, if a message is published to Mosquitto that has a topic starting with $, but that is not $SYS, e.g. $test/test, then an assert is triggered that should otherwise not be reachable and Mosquitto will exit. | ||||
| CVE-2018-12551 | 1 Eclipse | 1 Mosquitto | 2024-08-05 | N/A |
| When Eclipse Mosquitto version 1.0 to 1.5.5 (inclusive) is configured to use a password file for authentication, any malformed data in the password file will be treated as valid. This typically means that the malformed data becomes a username and no password. If this occurs, clients can circumvent authentication and get access to the broker by using the malformed username. In particular, a blank line will be treated as a valid empty username. Other security measures are unaffected. Users who have only used the mosquitto_passwd utility to create and modify their password files are unaffected by this vulnerability. | ||||
| CVE-2018-12550 | 1 Eclipse | 1 Mosquitto | 2024-08-05 | N/A |
| When Eclipse Mosquitto version 1.0 to 1.5.5 (inclusive) is configured to use an ACL file, and that ACL file is empty, or contains only comments or blank lines, then Mosquitto will treat this as though no ACL file has been defined and use a default allow policy. The new behaviour is to have an empty ACL file mean that all access is denied, which is not a useful configuration but is not unexpected. | ||||
| CVE-2018-12548 | 1 Eclipse | 1 Openj9 | 2024-08-05 | N/A |
| 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-12546 | 1 Eclipse | 1 Mosquitto | 2024-08-05 | 6.5 Medium |
| In Eclipse Mosquitto version 1.0 to 1.5.5 (inclusive) when a client publishes a retained message to a topic, then has its access to that topic revoked, the retained message will still be published to clients that subscribe to that topic in the future. In some applications this may result in clients being able cause effects that would otherwise not be allowed. | ||||
| CVE-2018-12536 | 3 Eclipse, Oracle, Redhat | 3 Jetty, Retail Xstore Point Of Service, Jboss Fuse | 2024-08-05 | 5.3 Medium |
| 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-2018-12544 | 2 Eclipse, Redhat | 2 Vert.x, Openshift Application Runtimes | 2024-08-05 | N/A |
| In version from 3.5.Beta1 to 3.5.3 of Eclipse Vert.x, the OpenAPI XML type validator creates XML parsers without taking appropriate defense against XML attacks. This mechanism is exclusively when the developer uses the Eclipse Vert.x OpenAPI XML type validator to validate a provided schema. | ||||
| CVE-2018-12539 | 3 Eclipse, Oracle, Redhat | 4 Openj9, Enterprise Manager Base Platform, Network Satellite and 1 more | 2024-08-05 | N/A |
| In Eclipse OpenJ9 version 0.8, users other than the process owner may be able to use Java Attach API to connect to an Eclipse OpenJ9 or IBM JVM on the same machine and use Attach API operations, which includes the ability to execute untrusted native code. Attach API is enabled by default on Windows, Linux and AIX JVMs and can be disabled using the command line option -Dcom.ibm.tools.attach.enable=no. | ||||
| CVE-2018-12545 | 2 Eclipse, Fedoraproject | 2 Jetty, Fedora | 2024-08-05 | 7.5 High |
| 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-12542 | 2 Eclipse, Microsoft | 2 Vert.x, Windows | 2024-08-05 | N/A |
| In version from 3.0.0 to 3.5.3 of Eclipse Vert.x, the StaticHandler uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\' (forward slashes) sequences that can resolve to a location that is outside of that directory when running on Windows Operating Systems. | ||||
| CVE-2018-12538 | 2 Eclipse, Netapp | 12 Jetty, E-series Santricity Management Plug-ins, E-series Santricity Os Controller and 9 more | 2024-08-05 | N/A |
| 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-2018-12541 | 2 Eclipse, Redhat | 3 Vert.x, Jboss Fuse, Openshift Application Runtimes | 2024-08-05 | 6.5 Medium |
| 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 | 2 Eclipse, Redhat | 3 Vert.x, Jboss Fuse, Openshift Application Runtimes | 2024-08-05 | N/A |
| 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-12547 | 2 Eclipse, Redhat | 8 Openj9, Enterprise Linux, Enterprise Linux Desktop and 5 more | 2024-08-05 | N/A |
| 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-12540 | 2 Eclipse, Redhat | 2 Vert.x, Openshift Application Runtimes | 2024-08-05 | N/A |
| 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-2019-18213 | 3 Eclipse, Theia Xml Extension Project, Xml Language Server Project | 3 Wild Web Developer, Theia Xml Extension, Xml Server Project | 2024-08-05 | 8.8 High |
| XML Language Server (aka lsp4xml) before 0.9.1, as used in Red Hat XML Language Support (aka vscode-xml) before 0.9.1 for Visual Studio and other products, allows XXE via a crafted XML document, with resultant SSRF (as well as SMB connection initiation that can lead to NetNTLM challenge/response capture for password cracking). This occurs in extensions/contentmodel/participants/diagnostics/LSPXMLParserConfiguration.java. | ||||
| CVE-2019-18212 | 3 Eclipse, Theia Xml Extension Project, Xml Language Server Project | 3 Wild Web Developer, Theia Xml Extension, Xml Server Project | 2024-08-05 | 6.5 Medium |
| XMLLanguageService.java in XML Language Server (aka lsp4xml) before 0.9.1, as used in Red Hat XML Language Support (aka vscode-xml) before 0.9.1 for Visual Studio and other products, allows a remote attacker to write to arbitrary files via Directory Traversal. | ||||
| CVE-2019-17640 | 1 Eclipse | 1 Vert.x | 2024-08-05 | 9.8 Critical |
| In Eclipse Vert.x 3.4.x up to 3.9.4, 4.0.0.milestone1, 4.0.0.milestone2, 4.0.0.milestone3, 4.0.0.milestone4, 4.0.0.milestone5, 4.0.0.Beta1, 4.0.0.Beta2, and 4.0.0.Beta3, StaticHandler doesn't correctly processes back slashes on Windows Operating systems, allowing, escape the webroot folder to the current working directory. | ||||
| CVE-2019-17634 | 1 Eclipse | 1 Memory Analyzer | 2024-08-05 | 9.0 Critical |
| Eclipse Memory Analyzer version 1.9.1 and earlier is subject to a cross site scripting (XSS) vulnerability when generating an HTML report from a malicious heap dump. The user must chose todownload, open the malicious heap dump and generate an HTML report for the problem to occur. The heap dump could be specially crafted, or could come from a crafted application or from an application processing malicious data. The vulnerability is present whena report is generated and opened from the Memory Analyzer graphical user interface, or when a report generated in batch mode is then opened in Memory Analyzer or by a web browser. The vulnerability could possibly allow code execution on the local system whenthe report is opened in Memory Analyzer. | ||||
| CVE-2019-17638 | 2 Eclipse, Redhat | 3 Jetty, Jboss Fuse, Openshift | 2024-08-05 | 9.4 Critical |
| In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with other data. Thread1 then proceeds to write the buffer that now contains different data. This results in client1, which issued request1 seeing data from another request or response which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.). If the Jetty version cannot be upgraded, the vulnerability can be significantly reduced by configuring a responseHeaderSize significantly larger than the requestHeaderSize (12KB responseHeaderSize and 8KB requestHeaderSize). | ||||