Search
Search Results (8 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-118488 | 2 Eclipse, Eclipse Foundation | 2 Vert.x, Vert.x | 2026-11-03 | 5.9 Medium |
| In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], when a malicious server keeps sending bytes on an EOL-terminated line (not length-prefixed, for example a simple string [1]), we'll keep growing the buffer without bounds, eventually leading to an OOM. We need to have a configurable limit for EOL-terminated lines. If a malicious server sends a specially crafted RESP response (for example a bulk string [2] with missing CRLF trailer), the parser enters an infinite loop where it keeps parsing the same buffer and pushing the same response to the caller, which may lead e.g. to an OOM if the consumer just buffers the responses. We must fix the parser to avoid this infinite looping. | ||||
| CVE-2020-35217 | 1 Eclipse | 1 Vert.x-web | 2024-11-21 | 8.8 High |
| Vert.x-Web framework v4.0 milestone 1-4 does not perform a correct CSRF verification. Instead of comparing the CSRF token in the request with the CSRF token in the cookie, it compares the CSRF token in the cookie against a CSRF token that is stored in the session. An attacker does not even need to provide a CSRF token in the request because the framework does not consider it. The cookies are automatically sent by the browser and the verification will always succeed, leading to a successful CSRF attack. | ||||
| CVE-2019-17640 | 1 Eclipse | 1 Vert.x | 2024-11-21 | 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-2018-12544 | 2 Eclipse, Redhat | 2 Vert.x, Openshift Application Runtimes | 2024-11-21 | 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-12542 | 2 Eclipse, Microsoft | 2 Vert.x, Windows | 2024-11-21 | 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-12541 | 2 Eclipse, Redhat | 3 Vert.x, Jboss Fuse, Openshift Application Runtimes | 2024-11-21 | 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-12540 | 2 Eclipse, Redhat | 2 Vert.x, Openshift Application Runtimes | 2024-11-21 | 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-2018-12537 | 2 Eclipse, Redhat | 3 Vert.x, Jboss Fuse, Openshift Application Runtimes | 2024-11-21 | 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. | ||||
Page 1 of 1.