CVSS: 8.8EPSS: 0%CPEs: 3EXPL: 0CVE-2023-4759 – Improper handling of case insensitive filesystems in Eclipse JGit allows arbitrary file write
https://notcve.org/view.php?id=CVE-2023-4759
Arbitrary File Overwrite in Eclipse JGit <= 6.6.0 In Eclipse JGit, all versions <= 6.6.0.202305301015-r, a symbolic link present in a specially crafted git repository can be used to write a file to locations outside the working tree when this repository is cloned with JGit to a case-insensitive filesystem, or when a checkout from a clone of such a repository is performed on a case-insensitive filesystem. This can happen on checkout (DirCacheCheckout), merge (ResolveMerger via its WorkingTreeUpdater), pull (PullCommand using merge), and when applying a patch (PatchApplier). This can be exploited for remote code execution (RCE), for instance if the file written outside the working tree is a git filter that gets executed on a subsequent git command. The issue occurs only on case-insensitive filesystems, like the default filesystems on Windows and macOS. The user performing the clone or checkout must have the rights to create symbolic links for the problem to occur, and symbolic links must be enabled in the git configuration. Setting git configuration option core.symlinks = false before checking out avoids the problem. The issue was fixed in Eclipse JGit version 6.6.1.202309021850-r and 6.7.0.202309050840-r, available via Maven Central https://repo1.maven.org/maven2/org/eclipse/jgit/ and repo.eclipse.org https://repo.eclipse.org/content/repositories/jgit-releases/ . A backport is available in 5.13.3 starting from 5.13.3.202401111512-r. The JGit maintainers would like to thank RyotaK for finding and reporting this issue. Sobrescritura Arbitraria de Archivos en Eclipse JGit <= 6.6.0 En Eclipse JGit, todas las versiones <= 6.6.0.202305301015-r, se puede utilizar un enlace simbólico presente en un repositorio git especialmente manipulado para escribir un archivo en ubicaciones fuera del árbol de trabajo cuando esto el repositorio se clona con JGit en un sistema de archivos que no distingue entre mayúsculas y minúsculas, o cuando se realiza una extracción de un clon de dicho repositorio en un sistema de archivos que no distingue entre mayúsculas y minúsculas. • https://git.eclipse.org/c/jgit/jgit.git/commit/?id=9072103f3b3cf64dd12ad2949836ab98f62dabf1 https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/11 https://projects.eclipse.org/projects/technology.jgit/releases/6.6.1 https://access.redhat.com/security/cve/CVE-2023-4759 https://bugzilla.redhat.com/show_bug.cgi?id=2238614 • CWE-59: Improper Link Resolution Before File Access ('Link Following') CWE-178: Improper Handling of Case Sensitivity •
CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2023-28366 – mosquitto: memory leak leads to unresponsive broker
https://notcve.org/view.php?id=CVE-2023-28366
The broker in Eclipse Mosquitto 1.3.2 through 2.x before 2.0.16 has a memory leak that can be abused remotely when a client sends many QoS 2 messages with duplicate message IDs, and fails to respond to PUBREC commands. This occurs because of mishandling of EAGAIN from the libc send function. El intermediario en Eclipse Mosquitto 1.3.2 hasta 2.x anterior a 2.0.16 tiene una pérdida de memoria de la que se puede abusar de forma remota cuando un cliente envía muchos mensajes QoS 2 con ID de mensajes duplicados y no responde a los comandos PUBREC. Esto ocurre debido a un mal manejo de EAGAIN desde la función de envío de libc. A memory leak vulnerability was found in Eclipse Mosquitto. • https://github.com/eclipse/mosquitto/commit/6113eac95a9df634fbc858be542c4a0456bfe7b9 https://github.com/eclipse/mosquitto/compare/v2.0.15...v2.0.16 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/KJ2FMBGVVQEQWTTQB7YLKTAHMX2UM66X https://mosquitto.org/blog/2023/08/version-2-0-16-released https://security.gentoo.org/glsa/202401-09 https://www.compass-security.com/fileadmin/Research/Advisories/2023_02_CSNC-2023-001_Eclipse_Mosquitto_Memory_Leak.txt https://www.debian&# • CWE-401: Missing Release of Memory after Effective Lifetime •
CVSS: 9.8EPSS: 0%CPEs: 13EXPL: 0CVE-2023-41034 – DDFFileParser in eclipse leshan is vulnerable to XXE Attacks
https://notcve.org/view.php?id=CVE-2023-41034
Eclipse Leshan is a device management server and client Java implementation. In affected versions DDFFileParser` and `DefaultDDFFileValidator` (and so `ObjectLoader`) are vulnerable to `XXE Attacks`. A DDF file is a LWM2M format used to store LWM2M object description. Leshan users are impacted only if they parse untrusted DDF files (e.g. if they let external users provide their own model), in that case they MUST upgrade to fixed version. If you parse only trusted DDF file and validate only with trusted xml schema, upgrading is not mandatory. • https://github.com/eclipse-leshan/leshan/commit/29577d2879ba8e7674c3b216a7f01193fc7ae013 https://github.com/eclipse-leshan/leshan/commit/4d3e63ac271a817f81fba3e3229c519af7a3049c https://github.com/eclipse-leshan/leshan/security/advisories/GHSA-wc9j-gc65-3cm7 https://github.com/eclipse-leshan/leshan/wiki/Adding-new-objects#the-lwm2m-model https://owasp.org/www-community/vulnerabilities/XML_External_Entity_(XXE)_Processing • CWE-611: Improper Restriction of XML External Entity Reference •
CVSS: 9.1EPSS: 0%CPEs: 1EXPL: 0CVE-2023-2597
https://notcve.org/view.php?id=CVE-2023-2597
In Eclipse Openj9 before version 0.38.0, in the implementation of the shared cache (which is enabled by default in OpenJ9 builds) the size of a string is not properly checked against the size of the buffer. • https://github.com/eclipse-openj9/openj9/pull/17259 https://security.netapp.com/advisory/ntap-20240621-0006 • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CWE-125: Out-of-bounds Read •
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 •