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.

Eclipse Vert.x before version 3.5.2 does not properly neutralize CR and LF characters in HTTP request before return responses. A remote attacker could exploit this to inject abritrary HTTP response headers to potentially mount cross-site scripting and cache poisoning attacks.

External Reference:

https://www.compass-security.com/fileadmin/Datein/Research/Advisories/CSNC-2018-021vertx.txt

Upstream Issue:

https://github.com/eclipse/vert.x/issues/2470

Upstream Patch:

https://github.com/eclipse/vert.x/commit/1bb6445226c39a95e7d07ce3caaf56828e8aab72

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.

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.