Filtered by vendor Redhat
Subscriptions
Filtered by product Jboss Enterprise Web Server
Subscriptions
Total
273 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-42794 | 2 Apache, Redhat | 4 Tomcat, Enterprise Linux, Jboss Enterprise Web Server and 1 more | 2025-02-13 | 5.9 Medium |
| Incomplete Cleanup vulnerability in Apache Tomcat. The internal fork of Commons FileUpload packaged with Apache Tomcat 9.0.70 through 9.0.80 and 8.5.85 through 8.5.93 included an unreleased, in progress refactoring that exposed a potential denial of service on Windows if a web application opened a stream for an uploaded file but failed to close the stream. The file would never be deleted from disk creating the possibility of an eventual denial of service due to the disk being full. Users are recommended to upgrade to version 9.0.81 onwards or 8.5.94 onwards, which fixes the issue. | ||||
| CVE-2023-28709 | 4 Apache, Debian, Netapp and 1 more | 5 Tomcat, Debian Linux, 7-mode Transition Tool and 2 more | 2025-02-13 | 7.5 High |
| The fix for CVE-2023-24998 was incomplete for Apache Tomcat 11.0.0-M2 to 11.0.0-M4, 10.1.5 to 10.1.7, 9.0.71 to 9.0.73 and 8.5.85 to 8.5.87. If non-default HTTP connector settings were used such that the maxParameterCount could be reached using query string parameters and a request was submitted that supplied exactly maxParameterCount parameters in the query string, the limit for uploaded request parts could be bypassed with the potential for a denial of service to occur. | ||||
| CVE-2023-24998 | 3 Apache, Debian, Redhat | 7 Commons Fileupload, Debian Linux, Camel Spring Boot and 4 more | 2025-02-13 | 7.5 High |
| Apache Commons FileUpload before 1.5 does not limit the number of request parts to be processed resulting in the possibility of an attacker triggering a DoS with a malicious upload or series of uploads. Note that, like all of the file upload limits, the new configuration option (FileUploadBase#setFileCountMax) is not enabled by default and must be explicitly configured. | ||||
| CVE-2023-41080 | 3 Apache, Debian, Redhat | 7 Tomcat, Debian Linux, Amq Broker and 4 more | 2025-02-13 | 6.1 Medium |
| URL Redirection to Untrusted Site ('Open Redirect') vulnerability in FORM authentication feature Apache Tomcat.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.0.12, from 9.0.0-M1 through 9.0.79 and from 8.5.0 through 8.5.92. The vulnerability is limited to the ROOT (default) web application. | ||||
| CVE-2021-25329 | 4 Apache, Debian, Oracle and 1 more | 15 Tomcat, Debian Linux, Agile Plm and 12 more | 2025-02-13 | 7.0 High |
| The fix for CVE-2020-9484 was incomplete. When using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue. | ||||
| CVE-2021-25122 | 4 Apache, Debian, Oracle and 1 more | 15 Tomcat, Debian Linux, Agile Plm and 12 more | 2025-02-13 | 7.5 High |
| When responding to new h2c connection requests, Apache Tomcat versions 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41 and 8.5.0 to 8.5.61 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request. | ||||
| CVE-2021-24122 | 4 Apache, Debian, Oracle and 1 more | 6 Tomcat, Debian Linux, Agile Plm and 3 more | 2025-02-13 | 5.9 Medium |
| When serving resources from a network location using the NTFS file system, Apache Tomcat versions 10.0.0-M1 to 10.0.0-M9, 9.0.0.M1 to 9.0.39, 8.5.0 to 8.5.59 and 7.0.0 to 7.0.106 were susceptible to JSP source code disclosure in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances. | ||||
| CVE-2021-22696 | 3 Apache, Oracle, Redhat | 8 Cxf, Business Intelligence, Communications Diameter Intelligence Hub and 5 more | 2025-02-13 | 7.5 High |
| CXF supports (via JwtRequestCodeFilter) passing OAuth 2 parameters via a JWT token as opposed to query parameters (see: The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)). Instead of sending a JWT token as a "request" parameter, the spec also supports specifying a URI from which to retrieve a JWT token from via the "request_uri" parameter. CXF was not validating the "request_uri" parameter (apart from ensuring it uses "https) and was making a REST request to the parameter in the request to retrieve a token. This means that CXF was vulnerable to DDos attacks on the authorization server, as specified in section 10.4.1 of the spec. This issue affects Apache CXF versions prior to 3.4.3; Apache CXF versions prior to 3.3.10. | ||||
| CVE-2020-17527 | 5 Apache, Debian, Netapp and 2 more | 15 Tomcat, Debian Linux, Element Plug-in and 12 more | 2025-02-13 | 7.5 High |
| While investigating bug 64830 it was discovered that Apache Tomcat 10.0.0-M1 to 10.0.0-M9, 9.0.0-M1 to 9.0.39 and 8.5.0 to 8.5.59 could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests. | ||||
| CVE-2023-28708 | 2 Apache, Redhat | 3 Tomcat, Enterprise Linux, Jboss Enterprise Web Server | 2025-02-13 | 4.3 Medium |
| When using the RemoteIpFilter with requests received from a reverse proxy via HTTP that include the X-Forwarded-Proto header set to https, session cookies created by Apache Tomcat 11.0.0-M1 to 11.0.0.-M2, 10.1.0-M1 to 10.1.5, 9.0.0-M1 to 9.0.71 and 8.5.0 to 8.5.85 did not include the secure attribute. This could result in the user agent transmitting the session cookie over an insecure channel. | ||||
| CVE-2024-38286 | 3 Apache, Netapp, Redhat | 8 Tomcat, Ontap Tools, Enterprise Linux and 5 more | 2025-02-11 | 8.6 High |
| Allocation of Resources Without Limits or Throttling vulnerability in Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M20, from 10.1.0-M1 through 10.1.24, from 9.0.13 through 9.0.89. Older, unsupported versions may also be affected. Users are recommended to upgrade to version 11.0.0-M21, 10.1.25, or 9.0.90, which fixes the issue. Apache Tomcat, under certain configurations on any platform, allows an attacker to cause an OutOfMemoryError by abusing the TLS handshake process. | ||||
| CVE-2024-52316 | 2 Apache, Redhat | 2 Tomcat, Jboss Enterprise Web Server | 2025-01-24 | 9.8 Critical |
| Unchecked Error Condition vulnerability in Apache Tomcat. If Tomcat is configured to use a custom Jakarta Authentication (formerly JASPIC) ServerAuthContext component which may throw an exception during the authentication process without explicitly setting an HTTP status to indicate failure, the authentication may not fail, allowing the user to bypass the authentication process. There are no known Jakarta Authentication components that behave in this way. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M26, from 10.1.0-M1 through 10.1.30, from 9.0.0-M1 through 9.0.95. Users are recommended to upgrade to version 11.0.0, 10.1.31 or 9.0.96, which fix the issue. | ||||
| CVE-2024-56337 | 1 Redhat | 1 Jboss Enterprise Web Server | 2025-01-03 | 9.8 Critical |
| Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.0.97. The mitigation for CVE-2024-50379 was incomplete. Users running Tomcat on a case insensitive file system with the default servlet write enabled (readonly initialisation parameter set to the non-default value of false) may need additional configuration to fully mitigate CVE-2024-50379 depending on which version of Java they are using with Tomcat: - running on Java 8 or Java 11: the system property sun.io.useCanonCaches must be explicitly set to false (it defaults to true) - running on Java 17: the system property sun.io.useCanonCaches, if set, must be set to false (it defaults to false) - running on Java 21 onwards: no further configuration is required (the system property and the problematic cache have been removed) Tomcat 11.0.3, 10.1.35 and 9.0.99 onwards will include checks that sun.io.useCanonCaches is set appropriately before allowing the default servlet to be write enabled on a case insensitive file system. Tomcat will also set sun.io.useCanonCaches to false by default where it can. | ||||
| CVE-2024-34750 | 1 Redhat | 3 Enterprise Linux, Jboss Enterprise Web Server, Rhel Eus | 2024-11-21 | 7.5 High |
| Improper Handling of Exceptional Conditions, Uncontrolled Resource Consumption vulnerability in Apache Tomcat. When processing an HTTP/2 stream, Tomcat did not handle some cases of excessive HTTP headers correctly. This led to a miscounting of active HTTP/2 streams which in turn led to the use of an incorrect infinite timeout which allowed connections to remain open which should have been closed. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M20, from 10.1.0-M1 through 10.1.24, from 9.0.0-M1 through 9.0.89. Users are recommended to upgrade to version 11.0.0-M21, 10.1.25 or 9.0.90, which fixes the issue. | ||||
| CVE-2023-5678 | 2 Openssl, Redhat | 5 Openssl, Enterprise Linux, Jboss Core Services and 2 more | 2024-11-21 | 5.3 Medium |
| Issue summary: Generating excessively long X9.42 DH keys or checking excessively long X9.42 DH keys or parameters may be very slow. Impact summary: Applications that use the functions DH_generate_key() to generate an X9.42 DH key may experience long delays. Likewise, applications that use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check() to check an X9.42 DH key or X9.42 DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service. While DH_check() performs all the necessary checks (as of CVE-2023-3817), DH_check_pub_key() doesn't make any of these checks, and is therefore vulnerable for excessively large P and Q parameters. Likewise, while DH_generate_key() performs a check for an excessively large P, it doesn't check for an excessively large Q. An application that calls DH_generate_key() or DH_check_pub_key() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack. DH_generate_key() and DH_check_pub_key() are also called by a number of other OpenSSL functions. An application calling any of those other functions may similarly be affected. The other functions affected by this are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate(). Also vulnerable are the OpenSSL pkey command line application when using the "-pubcheck" option, as well as the OpenSSL genpkey command line application. The OpenSSL SSL/TLS implementation is not affected by this issue. The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue. | ||||
| CVE-2022-4245 | 2 Codehaus-plexus, Redhat | 23 Plexus-utils, A Mq Clients, Amq Broker and 20 more | 2024-11-21 | 4.3 Medium |
| A flaw was found in codehaus-plexus. The org.codehaus.plexus.util.xml.XmlWriterUtil#writeComment fails to sanitize comments for a --> sequence. This issue means that text contained in the command string could be interpreted as XML and allow for XML injection. | ||||
| CVE-2022-4132 | 2 Dogtagpki, Redhat | 3 Network Security Services For Java, Enterprise Linux, Jboss Enterprise Web Server | 2024-11-21 | 5.9 Medium |
| A flaw was found in JSS. A memory leak in JSS requires non-standard configuration but is a low-effort DoS vector if configured that way (repeatedly hitting the login page). | ||||
| CVE-2022-45143 | 2 Apache, Redhat | 4 Tomcat, Jboss Enterprise Web Server, Jboss Fuse and 1 more | 2024-11-21 | 7.5 High |
| The JsonErrorReportValve in Apache Tomcat 8.5.83, 9.0.40 to 9.0.68 and 10.1.0-M1 to 10.1.1 did not escape the type, message or description values. In some circumstances these are constructed from user provided data and it was therefore possible for users to supply values that invalidated or manipulated the JSON output. | ||||
| CVE-2022-23307 | 4 Apache, Oracle, Qos and 1 more | 44 Chainsaw, Log4j, Advanced Supply Chain Planning and 41 more | 2024-11-21 | 8.8 High |
| CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists. | ||||
| CVE-2022-23305 | 6 Apache, Broadcom, Netapp and 3 more | 46 Log4j, Brocade Sannav, Snapmanager and 43 more | 2024-11-21 | 9.8 Critical |
| By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions. | ||||