CVSS: 6.9EPSS: 0%CPEs: 1EXPL: 0CVE-2024-8391 – Eclipse Vert.x gRPC server does not limit the maximum message size
https://notcve.org/view.php?id=CVE-2024-8391
In Eclipse Vert.x version 4.3.0 to 4.5.9, the gRPC server does not limit the maximum length of message payload (Maven GAV: io.vertx:vertx-grpc-server and io.vertx:vertx-grpc-client). This is fixed in the 4.5.10 version. Note this does not affect the Vert.x gRPC server based grpc-java and Netty libraries (Maven GAV: io.vertx:vertx-grpc) A flaw was found in the gRPC server in Eclipse Vert.x, which does not limit the maximum length of the message payload. This may lead to excessive memory consumption in a server or a client, causing a denial of service. • https://github.com/eclipse-vertx/vertx-grpc/issues/113 https://gitlab.eclipse.org/security/cve-assignement/-/issues/31 https://access.redhat.com/security/cve/CVE-2024-8391 https://bugzilla.redhat.com/show_bug.cgi?id=2309758 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 6.5EPSS: 0%CPEs: 2EXPL: 0CVE-2023-32081 – Vert.x STOMP server process client frames that would not send initially a connect frame
https://notcve.org/view.php?id=CVE-2023-32081
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. • https://github.com/vert-x3/vertx-stomp/commit/0de4bc5a44ddb57e74d92c445f16456fa03f265b https://github.com/vert-x3/vertx-stomp/security/advisories/GHSA-gvrq-cg5r-7chp • CWE-287: Improper Authentication •
CVSS: 5.3EPSS: 0%CPEs: 1EXPL: 1CVE-2023-24815 – Disclosure of classpath resources on Windows when mounted on a wildcard route in vertx-web
https://notcve.org/view.php?id=CVE-2023-24815
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. • https://github.com/vert-x3/vertx-web/blob/62c0d66fa1c179ae6a4d57344631679a2b97e60f/vertx-web/src/main/java/io/vertx/ext/web/impl/Utils.java#L83 https://github.com/vert-x3/vertx-web/commit/9e3a783b1d1a731055e9049078b1b1494ece9c15 https://github.com/vert-x3/vertx-web/security/advisories/GHSA-53jx-vvf9-4x38 https://access.redhat.com/security/cve/CVE-2023-24815 https://bugzilla.redhat.com/show_bug.cgi?id=2209400 • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') •
CVSS: 8.8EPSS: 0%CPEs: 4EXPL: 0CVE-2020-35217
https://notcve.org/view.php?id=CVE-2020-35217
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. El framework Vert.x-Web versión v4.0 milestone 1-4, no lleva a cabo una comprobación de CSRF correcta. • https://github.com/vert-x3/vertx-web/pull/1613 • CWE-352: Cross-Site Request Forgery (CSRF) •
CVSS: 9.8EPSS: 0%CPEs: 9EXPL: 0CVE-2019-17640
https://notcve.org/view.php?id=CVE-2019-17640
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. En Eclipse Vert.x versiones 3.4.x hasta 3.9.4, versiones 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 y 4.0.0.Beta3, StaticHandler no procesa correctamente las barras diagonales inversas en los sistemas operativos Windows, permitiendo escapar la carpeta webroot en el directorio de trabajo actual • https://bugs.eclipse.org/bugs/show_bug.cgi?id=567416 https://lists.apache.org/thread.html/r591f6932560c8c46cee87415afed92924a982189fea7f7c9096f8e33%40%3Ccommits.pulsar.apache.org%3E https://lists.apache.org/thread.html/r8383b5e7344a8b872e430ad72241b84b83e9701d275c602cfe34a941%40%3Ccommits.servicecomb.apache.org%3E https://lists.apache.org/thread.html/r8d863b148efe778ce5f8f961d0cafeda399e681d3f0656233b4c5511%40%3Ccommits.pulsar.apache.org%3E https://lists.apache.org/thread.html/rd0e44e8ef71eeaaa3cf3d1b8b41eb25894372e2995ec908ce7624d26%40%3Ccommits.pulsar.apache.org%3E https:/&# • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') CWE-23: Relative Path Traversal •