CVSS: 9.0EPSS: 0%CPEs: 2EXPL: 0CVE-2020-27220
https://notcve.org/view.php?id=CVE-2020-27220
The Eclipse Hono AMQP and MQTT protocol adapters do not check whether an authenticated gateway device is authorized to receive command & control messages when it has subscribed only to commands for a specific device. The missing check involves verifying that the command target device is configured giving permission for the gateway device to act on its behalf. This means an authenticated device of a certain tenant, notably also a non-gateway device acting like a gateway, may receive command & control messages targeted at a different device of the same tenant without corresponding permissions getting checked. Los adaptadores de protocolo AMQP y MQTT de Eclipse Hono no comprueban si un dispositivo gateway autenticado está autorizado para recibir mensajes de comando y control cuando se ha suscrito solo a comandos para un dispositivo específico. La falta de comprobación implica verificar que el dispositivo de destino del comando esté configurado dando permiso para que el dispositivo gateway actúe en su nombre. • https://bugs.eclipse.org/bugs/show_bug.cgi?id=569856 • CWE-862: Missing Authorization •
CVSS: 6.1EPSS: 0%CPEs: 7EXPL: 0CVE-2020-27219
https://notcve.org/view.php?id=CVE-2020-27219
In all version of Eclipse Hawkbit prior to 0.3.0M7, the HTTP 404 (Not Found) JSON response body returned by the REST API may contain unsafe characters within the path attribute. Sending a POST request to a non existing resource will return the full path from the given URL unescaped to the client. En todas las versiones de Eclipse Hawkbit anteriores a 0.3.0M7, el cuerpo de respuesta JSON HTTP 404 (No Found) devuelto mediante la API REST puede contener caracteres no seguros dentro del atributo de ruta. El envío de una petición POST a un recurso no existente devolverá la ruta completa desde la URL dada sin escapar al cliente • https://bugs.eclipse.org/bugs/show_bug.cgi?id=570289 https://github.com/eclipse/hawkbit/issues/1067 • CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') •
CVSS: 7.1EPSS: 0%CPEs: 1EXPL: 1CVE-2020-14368
https://notcve.org/view.php?id=CVE-2020-14368
A flaw was found in Eclipse Che in versions prior to 7.14.0 that impacts CodeReady Workspaces. When configured with cookies authentication, Theia IDE doesn't properly set the SameSite value, allowing a Cross-Site Request Forgery (CSRF) and consequently allowing a cross-site WebSocket hijack on Theia IDE. This flaw allows an attacker to gain full access to the victim's workspace through the /services endpoint. To perform a successful attack, the attacker conducts a Man-in-the-middle attack (MITM) and tricks the victim into executing a request via an untrusted link, which performs the CSRF and the Socket hijack. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. • https://github.com/codingchili/CVE-2020-14368 https://bugzilla.redhat.com/show_bug.cgi?id=1823892 • CWE-352: Cross-Site Request Forgery (CSRF) •
CVSS: 5.8EPSS: 1%CPEs: 27EXPL: 0CVE-2020-27218 – jetty: buffer not correctly recycled in Gzip Request inflation
https://notcve.org/view.php?id=CVE-2020-27218
In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request. En Eclipse Jetty versión 9.4.0.RC0 hasta 9.4.34.v20201102, 10.0.0.alpha0 hasta 10.0.0.beta2 y 11.0.0.alpha0 hasta 11.0.0.beta2, si la inflación del cuerpo de la petición GZIP está habilitada y solicita de diferentes clientes se multiplexan en una sola conexión, y si un atacante puede enviar una petición con un cuerpo que es recibido por completo pero no consumido por la aplicación, entonces una petición posterior en la misma conexión verá ese cuerpo antepuesto a su cuerpo. El atacante no verá ningún dato, pero puede inyectar datos en el cuerpo de la petición posterior • https://bugs.eclipse.org/bugs/show_bug.cgi?id=568892 https://github.com/eclipse/jetty.project/security/advisories/GHSA-86wm-rrjm-8wh8 https://lists.apache.org/thread.html/r00858fe27ee35ac8fa0e1549d67e0efb789d63b791b5300390bd8480%40%3Cjira.kafka.apache.org%3E https://lists.apache.org/thread.html/r01806ad8c9cb0590584baf5b1a60237ad92e4ad5bba082ca04d98179%40%3Creviews.spark.apache.org%3E https://lists.apache.org/thread.html/r05b7ffde2b8c180709e14bc9ca036407bea3ed9f09b32c4705d23a4a%40%3Cjira.kafka.apache.org%3E https://lists.apache.org/thread.html/r078c120 • CWE-226: Sensitive Information in Resource Not Removed Before Reuse •
CVSS: 7.5EPSS: 0%CPEs: 2EXPL: 0CVE-2020-27217
https://notcve.org/view.php?id=CVE-2020-27217
In Eclipse Hono version 1.3.0 and 1.4.0 the AMQP protocol adapter does not verify the size of AMQP messages received from devices. In particular, a device may send messages that are bigger than the max-message-size that the protocol adapter has indicated during link establishment. While the AMQP 1.0 protocol explicitly disallows a peer to send such messages, a hand crafted AMQP 1.0 client could exploit this behavior in order to send a message of unlimited size to the adapter, eventually causing the adapter to fail with an out of memory exception. En Eclipse Hono versiones 1.3.0 y 1.4.0, el adaptador de protocolo AMQP no verifica el tamaño de los mensajes AMQP recibidos desde dispositivos. En particular, un dispositivo puede enviar mensajes que son más grandes que el tamaño máximo de mensaje que el adaptador de protocolo ha indicado durante el establecimiento del enlace. • https://bugs.eclipse.org/bugs/show_bug.cgi?id=567068 • CWE-1284: Improper Validation of Specified Quantity in Input •