In Eclipse Sphinx™ before version 0.13.1, Apache Xerces XML Parser was used without disabling processing of referenced external entities allowing the injection of arbitrary definitions which is able to access local files and expose their contents via HTTP requests.

In Eclipse Kura versions up to 4.0.0, the Web UI package and component services, the Artemis simple Mqtt component and the emulator position service (not part of the device distribution) could potentially be target of XXE attack due to an improper factory and parser initialisation.

Dump Servlet information leak in jetty before 6.1.22.

For Eclipse Jetty versions 9.4.37-9.4.42, 10.0.1-10.0.5 & 11.0.1-11.0.5, URIs can be crafted using some encoded characters to access the content of the WEB-INF directory and/or bypass some security constraints. This is a variation of the vulnerability reported in CVE-2021-28164/GHSA-v7ff-8wcx-gmc5.

In Eclipse Mosquitto versions 2.0 to 2.0.11, when using the dynamic security plugin, if the ability for a client to make subscriptions on a topic is revoked when a durable client is offline, then existing subscriptions for that client are not revoked.

Eclipse TinyDTLS through 0.9-rc1 relies on the rand function in the C library, which makes it easier for remote attackers to compute the master key and then decrypt DTLS traffic.

The exception handling code in Eclipse Jetty before 9.2.9.v20150224 allows remote attackers to obtain sensitive information from process memory via illegal characters in an HTTP header, aka JetLeak.

The getLocalePrefix function in ResourceManager.java in Eclipse Mojarra before 2.3.7 is affected by Directory Traversal via the loc parameter. A remote attacker can download configuration files or Java bytecodes from applications.

In Eclipse Jetty Server, all 9.x versions, on webapps deployed using default Error Handling, when an intentionally bad query arrives that doesn't match a dynamic url-pattern, and is eventually handled by the DefaultServlet's static file serving, the bad characters can trigger a java.nio.file.InvalidPathException which includes the full path to the base resource directory that the DefaultServlet and/or webapp is using. If this InvalidPathException is then handled by the default Error Handler, the InvalidPathException message is included in the error response, revealing the full server path to the requesting system.

In Eclipse Jetty 9.4.37.v20210219 to 9.4.38.v20210224, the default compliance mode allows requests with URIs that contain %2e or %2e%2e segments to access protected resources within the WEB-INF directory. For example a request to /context/%2e/WEB-INF/web.xml can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application.

For Eclipse Jetty versions <= 9.4.40, <= 10.0.2, <= 11.0.2, it is possible for requests to the ConcatServlet with a doubly encoded path to access protected resources within the WEB-INF directory. For example a request to `/concat?/%2557EB-INF/web.xml` can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application.

Jetty through 9.4.x is prone to a timing channel in util/security/Password.java, which makes it easier for remote attackers to obtain access by observing elapsed times before rejection of incorrect passwords.

In Eclipse Kura versions up to 4.0.0, the SkinServlet did not checked the path passed during servlet call, potentially allowing path traversal in get requests for a limited number of file types.

Deeplearning4J is a suite of tools for deploying and training deep learning models using the JVM. Packages org.deeplearning4j:dl4j-examples and org.deeplearning4j:platform-tests through version 1.0.0-M2.1 may use some unclaimed S3 buckets in tests in examples. This is likely affect people who use some older NLP examples that reference an old S3 bucket. The problem has been patched. Users should upgrade to snapshots as Deeplearning4J plan to publish a release with the fix at a later date. As a workaround, download a word2vec google news vector from a new source using git lfs from here.

Jetty is a java based web server and servlet engine. Nonstandard cookie parsing in Jetty may allow an attacker to smuggle cookies within other cookies, or otherwise perform unintended behavior by tampering with the cookie parsing mechanism. If Jetty sees a cookie VALUE that starts with `"` (double quote), it will continue to read the cookie string until it sees a closing quote -- even if a semicolon is encountered. So, a cookie header such as: `DISPLAY_LANGUAGE="b; JSESSIONID=1337; c=d"` will be parsed as one cookie, with the name DISPLAY_LANGUAGE and a value of b; JSESSIONID=1337; c=d instead of 3 separate cookies. This has security implications because if, say, JSESSIONID is an HttpOnly cookie, and the DISPLAY_LANGUAGE cookie value is rendered on the page, an attacker can smuggle the JSESSIONID cookie into the DISPLAY_LANGUAGE cookie and thereby exfiltrate it. This is significant when an intermediary is enacting some policy based on cookies, so a smuggled cookie can bypass that policy yet still be seen by the Jetty server or its logging system. This issue has been addressed in versions 9.4.51, 10.0.14, 11.0.14, and 12.0.0.beta0 and users are advised to upgrade. There are no known workarounds for this issue.

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. There are no known workarounds for this vulnerability.

In Eclipse OpenJ9 prior to version 0.21 on Power platforms, calling the System.arraycopy method with a length longer than the length of the source or destination array can, in certain specially crafted code patterns, cause the current method to return prematurely with an undefined return value. This allows whatever value happens to be in the return register at that time to be used as if it matches the method's declared return type.

In Eclipse Kura versions up to 4.0.0, Kura exposes the underlying Ui Web server version in its replies. This can be used as a hint by an attacker to specifically craft attacks to the web server run by Kura.

In the Eclipse Paho Java client library version 1.2.0, when connecting to an MQTT server using TLS and setting a host name verifier, the result of that verification is not checked. This could allow one MQTT server to impersonate another and provide the client library with incorrect information.

In Eclipse Jetty version 9.2.27, 9.3.26, and 9.4.16, the server running on Windows is vulnerable to exposure of the fully qualified Base Resource directory name on Windows to a remote client when it is configured for showing a Listing of directory contents. This information reveal is restricted to only the content in the configured base resource directories.

In Eclipse Jetty version 7.x, 8.x, 9.2.27 and older, 9.3.26 and older, and 9.4.16 and older, the server running on any OS and Jetty version combination will reveal the configured fully qualified directory base resource location on the output of the 404 error for not finding a Context that matches the requested path. The default server behavior on jetty-distribution and jetty-home will include at the end of the Handler tree a DefaultHandler, which is responsible for reporting this 404 error, it presents the various configured contexts as HTML for users to click through to. This produced HTML includes output that contains the configured fully qualified directory base resource location for each context.

In Eclipse JGit versions 7.2.0.202503040940-r and older, the ManifestParser class used by the repo command and the AmazonS3 class used to implement the experimental amazons3 git transport protocol allowing to store git pack files in an Amazon S3 bucket, are vulnerable to XML External Entity (XXE) attacks when parsing XML files. This vulnerability can lead to information disclosure, denial of service, and other security issues.

In Eclipse Memory Analyzer versions 0.7 to 1.14.0, report definition XML files are not filtered to prohibit document type definition (DTD) references to external entities. This means that if a user chooses to use a malicious report definition XML file containing an external entity reference to generate a report then Eclipse Memory Analyzer may access external files or URLs defined via a DTD in the report definition.

In version from 3.5.Beta1 to 3.5.3 of Eclipse Vert.x, the OpenAPI XML type validator creates XML parsers without taking appropriate defense against XML attacks. This mechanism is exclusively when the developer uses the Eclipse Vert.x OpenAPI XML type validator to validate a provided schema.

In Eclipse IDE versions < 2023-09 (4.29) some files with xml content are parsed vulnerable against all sorts of XXE attacks. The user just needs to open any evil project or update an open project with a vulnerable file (for example for review a foreign repository or patch).

Eclipse XML parser for the Eclipse IDE versions 2017.2.5 and earlier was found vulnerable to an XML External Entity attack. An attacker can exploit the vulnerability by implementing malicious code on Androidmanifest.xml.

Eclipse RDF4j version < 2.4.0 Milestone 2 contains a XML External Entity (XXE) vulnerability in RDF4j XML parser parsing RDF files that can result in the disclosure of confidential data, denial of service, server side request forgery, port scanning. This attack appear to be exploitable via Specially crafted RDF file.

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. This issue has been fixed in versions 1.5.0 and 2.0.0-M13. Users are advised to upgrade. There are no known workarounds for this vulnerability.

XML Language Server (aka lsp4xml) before 0.9.1, as used in Red Hat XML Language Support (aka vscode-xml) before 0.9.1 for Visual Studio and other products, allows XXE via a crafted XML document, with resultant SSRF (as well as SMB connection initiation that can lead to NetNTLM challenge/response capture for password cracking). This occurs in extensions/contentmodel/participants/diagnostics/LSPXMLParserConfiguration.java.

In all versions of Eclipse Web Tools Platform through release 3.18 (2020-06), XML and DTD files referring to external entities could be exploited to send the contents of local files to a remote server when edited or validated, even when external entity resolution is disabled in the user preferences.

In Eclipse Theia 0.1.1 to 0.2.0, it is possible to exploit the default build to obtain remote code execution (and XXE) via the theia-xml-extension. This extension uses lsp4xml (recently renamed to LemMinX) in order to provide language support for XML. This is installed by default.

Hudson (aka org.jvnet.hudson.main:hudson-core) before 3.3.2 allows XXE attacks.

An XXE issue was discovered in Automated Logic Corporation (ALC) WebCTRL Versions 6.0, 6.1 and 6.5. An unauthenticated attacker could enter malicious input to WebCTRL and a weakly configured XML parser will allow the application to disclose full file contents from the underlying web server OS via the "X-Wap-Profile" HTTP header.

Apache Camel prior to 2.24.0 contains an XML external entity injection (XXE) vulnerability (CWE-611) due to using an outdated vulnerable JSON-lib library. This affects only the camel-xmljson component, which was removed.

An Improper Restriction of XML External Entity Reference ('XXE') vulnerability exists on numerous methods of the IIoT Monitor 3.1.38 software that could allow the software to resolve documents outside of the intended sphere of control, causing the software to embed incorrect documents into its output and expose restricted information.

On Feb 15, 2023, the following vulnerability in the ClamAV scanning library was disclosed: A vulnerability in the DMG file parser of ClamAV versions 1.0.0 and earlier, 0.105.1 and earlier, and 0.103.7 and earlier could allow an unauthenticated, remote attacker to access sensitive information on an affected device. This vulnerability is due to enabling XML entity substitution that may result in XML external entity injection. An attacker could exploit this vulnerability by submitting a crafted DMG file to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to leak bytes from any file that may be read by the ClamAV scanning process.

Schneider Electric SoMachine Basic prior to v1.6 SP1 suffers from an XML External Entity (XXE) vulnerability using the DTD parameter entities technique resulting in disclosure and retrieval of arbitrary data on the affected node via out-of-band (OOB) attack. The vulnerability is triggered when input passed to the xml parser is not sanitized while parsing the xml project/template file.

XML External Entity (XXE) Vulnerability in /SSOPOST/metaAlias/%realm%/idpv2 in OpenAM - Access Management 10.1.0 allows remote attackers to read arbitrary files via the SAMLRequest parameter.

Adobe ColdFusion Update 5 and earlier versions, ColdFusion 11 Update 13 and earlier versions have an exploitable Unsafe XML External Entity Processing vulnerability. Successful exploitation could lead to information disclosure.

XML External Entity (XXE) vulnerability in PySAML2 4.4.0 and earlier allows remote attackers to read arbitrary files via a crafted SAML XML request or response.

MailEnable before 8.60 allows XXE via an XML document in the request.aspx Options parameter.

BI Web Services in SAS Web Infrastructure Platform before 9.4M6 allows XXE.

An XML External Entity (XXE) vulnerability exists in the Charles 4.2.7 import/export setup option. If a user imports a "Charles Settings.xml" file from an attacker, an intranet network may be accessed and information may be leaked.

The data import functionality in OpenRefine through 3.1 allows an XML External Entity (XXE) attack through a crafted (zip) file, allowing attackers to read arbitrary files.

An XXE vulnerability exists in CASE Suite Versions 3.10 and prior when processing parameter entities, which may allow remote file disclosure.

The _clone function in XML::LibXML before 2.0119 does not properly set the expand_entities option, which allows remote attackers to conduct XML external entity (XXE) attacks via crafted XML data to the (1) new or (2) load_xml function.

Concrete CMS (formerly concrete5) below 8.5.10 and between 9.0.0 and 9.1.2 is vulnerable to XXE based DNS requests leading to IP disclosure.

XML external entity (XXE) vulnerability in CloudBees Jenkins before 1.600 and LTS before 1.596.1 allows remote attackers to read arbitrary XML files via an XPath query.

An XML external entity vulnerability in the XOG functionality, in CA PPM 14.3 and below, 14.4, 15.1, 15.2 CP5 and below, and 15.3 CP2 and below, allows remote attackers to access sensitive information.

Apereo Bedework bw-webdav before 4.0.3 allows XXE attacks, as demonstrated by an invite-reply document that reads a local file, related to webdav/servlet/common/MethodBase.java and webdav/servlet/common/PostRequestPars.java.