CVSS: 4.3EPSS: 0%CPEs: 11EXPL: 1CVE-2023-36479 – Jetty vulnerable to errant command quoting in CGI Servlet
https://notcve.org/view.php?id=CVE-2023-36479
Eclipse Jetty Canonical Repository is the canonical repository for the Jetty project. Users of the CgiServlet with a very specific command structure may have the wrong command executed. If a user sends a request to a org.eclipse.jetty.servlets.CGI Servlet for a binary with a space in its name, the servlet will escape the command by wrapping it in quotation marks. This wrapped command, plus an optional command prefix, will then be executed through a call to Runtime.exec. If the original binary name provided by the user contains a quotation mark followed by a space, the resulting command line will contain multiple tokens instead of one. • https://github.com/eclipse/jetty.project/pull/9516 https://github.com/eclipse/jetty.project/pull/9888 https://github.com/eclipse/jetty.project/pull/9889 https://github.com/eclipse/jetty.project/security/advisories/GHSA-3gh6-v5v9-6v9j https://lists.debian.org/debian-lts-announce/2023/09/msg00039.html https://www.debian.org/security/2023/dsa-5507 https://access.redhat.com/security/cve/CVE-2023-36479 https://bugzilla.redhat.com/show_bug.cgi?id=2239630 • CWE-149: Improper Neutralization of Quoting Syntax •
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 •