Where
-Infinity
0
Severity
9.8
XEE, Input Validation
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Spring Web Services, versions 2.4.3, 3.0.4, and older unsupported versions of all three projects, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.

1 / 2
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

A flaw was found in the Apache Commons BeanUtils, where the class property in PropertyUtilsBean is not suppressed by default. This flaw allows an attacker to access the classloader.

1 / 4
First published (updated )
Severity
7.5
Input Validation
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Pivotal Spring Framework is vulnerable to a denial of service, caused by improper handling of range request by the ResourceHttpRequestHandler. By adding a range header with a high number of ranges, a remote attacker could exploit this vulnerability to cause a denial of service condition.

1 / 3
Source: IBM
First published (updated )
Severity
6.5
XSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N

A vulnerability was found in Hibernate-Validator. The SafeHtml validator annotation fails to properly sanitize payloads consisting of potentially malicious code in HTML comments and instructions. This vulnerability can result in an XSS attack.

1 / 2
First published (updated )
Severity
7.5
Infoleak
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

All versions of Apache Santuario - XML Security for Java prior to 2.2.3 and 2.1.7 are vulnerable to an issue where the "secureValidation" property is not passed correctly when creating a KeyInfo from a KeyInfoReference element. This allows an attacker to abuse an XPath Transform to extract any local .xml files in a RetrievalMethod element.

1 / 3
First published (updated )
Severity
8.3
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H

Vulnerability in the Advanced Networking Option component of Oracle Database Server. Supported versions that are affected are 12.1.0.2, 12.2.0.1 and 19c. Difficult to exploit vulnerability allows unauthenticated attacker with network access via Oracle Net to compromise Advanced Networking Option. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Advanced Networking Option, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Advanced Networking Option. Note: The July 2021 Critical Patch Update introduces a number of Native Network Encryption changes to deal with vulnerability CVE-2021-2351 and prevent the use of weaker ciphers. Customers should review: "Changes in Native Network Encryption with the July 2021 Critical Patch Update" (Doc ID 2791571.1). CVSS 3.1 Base Score 8.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H).

First published (updated )
Severity
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

c3p0 version < 0.9.5.4 may be exploited by a billion laughs attack when loading XML configuration due to missing protections against recursive entity expansion when loading configuration.

1 / 2
First published (updated )
Severity
7.5
Code Injection
AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Apache Ant could allow a remote authenticated attacker to bypass security restrictions, caused by an insecure temporary file flaw. By sending a specially-crafted request, an attacker could exploit this vulnerability to inject modified source files into the build process.

1 / 3
Source: IBM
First published (updated )
Severity
6.5
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

Apache Ant 1.1 to 1.9.14 and 1.10.0 to 1.10.7 uses the default temporary directory identified by the Java system property java.io.tmpdir for several tasks and may thus leak sensitive information. The fixcrlf and replaceregexp tasks also copy files from the temporary directory back into the build tree allowing an attacker to inject modified source files into the build process.

1 / 4
First published (updated )
Severity
6.5
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

A flaw was found in Spring Framework, versions 5.0.x prior to 5.0.6, versions 4.3.x prior to 4.3.17, and older unsupported versions allows applications to expose STOMP over WebSocket endpoints with a simple, in-memory STOMP broker through the spring-messaging module. A malicious user (or attacker) can craft a message to the broker that can lead to a regular expression, denial of service attack.

References: https://pivotal.io/security/cve-2018-1257

1 / 3
Source: Red Hat
First published (updated )
Severity
7
Race Condition
AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Impact On Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.

Additionally, any user code uses of WebAppContext::getTempDirectory) would similarly be vulnerable.

Additionally, any user application code using the ServletContext attribute for the tempdir will also be impacted. See: https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletContext.html#TEMPDIR

For example: java import java.io.File; import java.io.IOException; import javax.servlet.ServletContext; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse;

public class ExampleServlet extends HttpServlet { @Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { File tempDir = (File)getServletContext().getAttribute(ServletContext.TEMPDIR); // Potentially compromised // do something with that temp dir } }

Example: The JSP library itself will use the container temp directory for compiling the JSP source into Java classes before executing them.

CVSSv3.1 Evaluation

This vulnerability has been calculated to have a CVSSv3.1 score of 7.8/10 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)

Patches Fixes were applied to the 9.4.x branch with: - https://github.com/eclipse/jetty.project/commit/53e0e0e9b25a6309bf24ee3b10984f4145701edb - https://github.com/eclipse/jetty.project/commit/9ad6beb80543b392c91653f6bfce233fc75b9d5f

These will be included in releases: 9.4.33, 10.0.0.beta3, 11.0.0.beta3

Workarounds

A work around is to set a temporary directory, either for the server or the context, to a directory outside of the shared temporary file system. For recent releases, a temporary directory can be created simple by creating a directory called work in the ${jetty.base} directory (the parent directory of the webapps directory). Alternately the java temporary directory can be set with the System Property java.io.tmpdir. A more detailed description of how jetty selects a temporary directory is below.

The Jetty search order for finding a temporary directory is as follows:

1. If the WebAppContext has a temp directory specified), use it. 2. If the ServletContext has the javax.servlet.context.tempdir attribute set, and if directory exists, use it. 3. If a ${jetty.base}/work directory exists, use it (since Jetty 9.1) 4. If a ServletContext has the org.eclipse.jetty.webapp.basetempdir attribute set, and if the directory exists, use it. 5. Use System.getProperty("java.io.tmpdir") and use it.

Jetty will end traversal at the first successful step. To mitigate this vulnerability the directory must be set to one that is not writable by an attacker. To avoid information leakage, the directory should also not be readable by an attacker.

Setting a Jetty server temporary directory.

Choices 3 and 5 apply to the server level, and will impact all deployed webapps on the server.

For choice 3 just create that work directory underneath your ${jetty.base} and restart Jetty.

For choice 5, just specify your own java.io.tmpdir when you start the JVM for Jetty.

shell [jetty-distribution]$ java -Djava.io.tmpdir=/var/web/work -jar start.jar

Setting a Context specific temporary directory.

The rest of the choices require you to configure the context for that deployed webapp (seen as ${jetty.base}/webapps/<context>.xml)

Example (excluding the DTD which is version specific):

xml <Configure class="org.eclipse.jetty.webapp.WebAppContext"> <Set name="contextPath"><Property name="foo"/></Set> <Set name="war">/var/web/webapps/foo.war</Set> <Set name="tempDirectory">/var/web/work/foo</Set> </Configure>

References - https://github.com/eclipse/jetty.project/issues/5451 - CWE-378: Creation of Temporary File With Insecure Permissions - CWE-379: Creation of Temporary File in Directory with Insecure Permissions - CodeQL Query PR To Detect Similar Vulnerabilities

Similar Vulnerabilities

Similar, but not the same.

- JUnit 4 - https://github.com/junit-team/junit4/security/advisories/GHSA-269g-pwp5-87pp - Google Guava - https://github.com/google/guava/issues/4011 - Apache Ant - https://nvd.nist.gov/vuln/detail/CVE-2020-1945 - JetBrains Kotlin Compiler - https://nvd.nist.gov/vuln/detail/CVE-2020-15824

For more information

The original report of this vulnerability is below:

On Thu, 15 Oct 2020 at 21:14, Jonathan Leitschuh <jonathan.leitschuh@gmail.com> wrote: Hi WebTide Security Team, I'm a security researcher writing some custom CodeQL queries to find Local Temporary Directory Hijacking Vulnerabilities. One of my queries flagged an issue in Jetty. https://lgtm.com/query/5615014766184643449/ I've recently been looking into security vulnerabilities involving the temporary directory because on unix-like systems, the system temporary directory is shared between all users. There exists a race condition between the deletion of the temporary file and the creation of the directory. java // ensure file will always be unique by appending random digits tmpDir = File.createTempFile(temp, ".dir", parent); // Attacker knows the full path of the file that will be generated // delete the file that was created tmpDir.delete(); // Attacker sees file is deleted and begins a race to create their own directory before Jetty. // and make a directory of the same name // SECURITY VULNERABILITY: Race Condition! - Attacker beats Jetty and now owns this directory tmpDir.mkdirs(); https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L511-L518 In several cases the parent parameter will not be the system temporary directory. However, there is one case where it will be, as the last fallback. https://github.com/eclipse/jetty.project/blob/1b59672b7f668b8a421690154b98b4b2b03f254b/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebInfConfiguration.java#L467-L468 If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability. Would your team be willing to open a GitHub security advisory to continue the discussion and disclosure there? https://github.com/eclipse/jetty.project/security/advisories This vulnerability disclosure follows Google's 90-day vulnerability disclosure policy (I'm not an employee of Google, I just like their policy). Full disclosure will occur either at the end of the 90-day deadline or whenever a patch is made widely available, whichever occurs first. Cheers, Jonathan Leitschuh

1 / 3
First published (updated )
Severity
4.8
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Impact 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 by not consumed by the application, then a subsequent request on the same connection will see that body prepended to it's body.

The attacker will not see any data, but may inject data into the body of the subsequent request

CVE score is 4.8 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L

Workarounds The problem can be worked around by either: - Disabling compressed request body inflation by GzipHandler. - By always fully consuming the request content before sending a response. - By adding a Connection: close to any response where the servlet does not fully consume request content.

1 / 4
Source: GitHub
First published (updated )
Severity
9.8
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

A flaw was found in cxf in versions prior to 3.2.11 and 3.3.4. The access token services do not properly validate that an authenticated principal is equal to that of the supplied clientId parameter allowing a malicious client to use an authorization code that has been issued to a different client as their own. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

1 / 3
First published (updated )
Severity
7.5
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Apache CXF could allow a remote attacker to obtain sensitive information, caused by a flaw when ships with OpenId Connect JWK Keys service. By accessing the JWK keystore file, an attacker could exploit this vulnerability to obtain the public keys in JWK format, and use this information to launch further attacks against the affected system.

1 / 3
Source: IBM
First published (updated )
Severity
5.9
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and Compound Ordering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service.

External References:

https://github.com/google/guava/wiki/CVE-2018-10237 https://groups.google.com/forum/#!topic/guava-announce/xqWALw4W1vs/discussion

Upstream Patch:

https://github.com/google/guava/commit/7ec8718f1e6e2814dabaa4b9f96b6b33a813101c

1 / 2
Source: Red Hat
First published (updated )
Severity
7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

XStream is an open source java library to serialize objects to XML and back again. Versions prior to 1.4.19 may allow a remote attacker to allocate 100% CPU time on the target system depending on CPU type or parallel execution of such a payload resulting in a denial of service only by manipulating the processed input stream. XStream 1.4.19 monitors and accumulates the time it takes to add elements to collections and throws an exception if a set threshold is exceeded. Users are advised to upgrade as soon as possible. Users unable to upgrade may set the NOREFERENCE mode to prevent recursion. See GHSA-rmr5-cpv2-vgjf for further details on a workaround if an upgrade is not possible.

1 / 2
First published (updated )
Severity
3.7
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Apache Log4j is vulnerable to a man-in-the-middle attack, caused by improper certificate validation with host mismatch in the SMTP appender. An attacker could exploit this vulnerability to launch a man-in-the-middle attack and gain access to the communication channel between endpoints to obtain sensitive information or further compromise the system.

1 / 4
Source: IBM
First published (updated )
Severity
6.5
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

Apache CXF before 3.3.4 and 3.2.11 does not restrict the number of message attachments present in a given message. This leaves open the possibility of a denial of service type attack, where a malicious user crafts a message containing a very large number of message attachments. From the 3.3.4 and 3.2.11 releases, a default limit of 50 message attachments is enforced. This is configurable via the message property "attachment-max-count".

1 / 3
First published (updated )
Severity
7.5
Input Validation
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Apache Camel's JMX is vulnerable to Rebind Flaw. Apache Camel 2.22.x, 2.23.x, 2.24.x, 2.25.x, 3.0.0 up to 3.1.0 is affected. Users should upgrade to 3.2.0.

1 / 2
First published (updated )
Severity
5.3
Infoleak
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

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.

1 / 2
First published (updated )
Severity
8
XSS
AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H

A flaw was found in springframework in versions prior to 5.0.16, 5.1.13, and 5.2.3. A reflected file download (RFD) attack is possible when a "Content-Disposition" header is set in response to where the filename attribute is derived from user supplied input. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.

1 / 4
First published (updated )
Severity
5.3
CSRF
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Spring Framework, versions 5.2.x prior to 5.2.3 are vulnerable to CSRF attacks through CORS preflight requests that target Spring MVC (spring-webmvc module) or Spring WebFlux (spring-webflux module) endpoints. Only non-authenticated endpoints are vulnerable because preflight requests should not include credentials and therefore requests should fail authentication. However a notable exception to this are Chrome based browsers when using client certificates for authentication since Chrome sends TLS client certificates in CORS preflight requests in violation of spec requirements. No HTTP body can be sent or received as a result of this attack.

First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

A carefully crafted or corrupt PSD file can cause excessive memory usage in Apache Tika's PSDParser in versions 1.0-1.23.

1 / 4
First published (updated )
Severity
5.5
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

A carefully crafted or corrupt PSD file can cause an infinite loop in Apache Tika's PSDParser in versions 1.0-1.23.

1 / 2
Source: Launchpad
First published (updated )
Severity
5.5
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N

Vulnerability in the Oracle FLEXCUBE Private Banking component of Oracle Financial Services Applications (subcomponent: Miscellaneous). Supported versions that are affected are 12.0.0 and 12.1.0. Easily "exploitable" vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle FLEXCUBE Private Banking. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle FLEXCUBE Private Banking accessible data as well as unauthorized read access to a subset of Oracle FLEXCUBE Private Banking accessible data. CVSS 3.0 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N).

First published (updated )
Severity
5
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L

Vulnerability in the Oracle FLEXCUBE Private Banking component of Oracle Financial Services Applications (subcomponent: Miscellaneous). Supported versions that are affected are 2.0.0, 2.0.1, 2.2.0.1 and 12.0.1. Easily "exploitable" vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle FLEXCUBE Private Banking. While the vulnerability is in Oracle FLEXCUBE Private Banking, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle FLEXCUBE Private Banking. CVSS 3.0 Base Score 5.0 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:L).

First published (updated )
Severity
5.5
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

Vulnerability in the Oracle FLEXCUBE Private Banking component of Oracle Financial Services Applications (subcomponent: Miscellaneous). Supported versions that are affected are 2.0.0, 2.0.1, 2.2.0.1 and 12.0.1. Easily "exploitable" vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle FLEXCUBE Private Banking. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle FLEXCUBE Private Banking accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle FLEXCUBE Private Banking. CVSS 3.0 Base Score 5.4 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L).

First published (updated )
Severity
4.9
CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N

Vulnerability in the Oracle FLEXCUBE Private Banking component of Oracle Financial Services Applications (subcomponent: Miscellaneous). Supported versions that are affected are 12.0.0 and 12.1.0. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle FLEXCUBE Private Banking. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle FLEXCUBE Private Banking accessible data as well as unauthorized read access to a subset of Oracle FLEXCUBE Private Banking accessible data. CVSS 3.0 Base Score 4.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N).

First published (updated )
Severity
7.5
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N

Vulnerability in the Oracle FLEXCUBE Private Banking component of Oracle Financial Services Applications (subcomponent: Miscellaneous). Supported versions that are affected are 2.0.0, 2.0.1, 2.2.0.1 and 12.0.1. Easily "exploitable" vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle FLEXCUBE Private Banking. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle FLEXCUBE Private Banking accessible data as well as unauthorized update, insert or delete access to some of Oracle FLEXCUBE Private Banking accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N).

First published (updated )
Severity
4.3
CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Vulnerability in the Oracle FLEXCUBE Private Banking component of Oracle Financial Services Applications (subcomponent: Miscellaneous). Supported versions that are affected are 2.0.0, 2.0.1, 2.2.0.1 and 12.0.1. Easily "exploitable" vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle FLEXCUBE Private Banking. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle FLEXCUBE Private Banking accessible data. CVSS 3.0 Base Score 4.3 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).

First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203