RHSA-2020:0983HighCVSS 9.8

Red Hat Security Advisory: Red Hat Fuse 7.6.0 security update

Published
March 26, 2020
Last Modified
August 15, 2026

🔗 CVE IDs covered (27)

CVE-2019-12422 →CVE-2019-12814 →CVE-2019-17570 →CVE-2017-16012 · pendingCVE-2018-11771 →CVE-2019-9514 →CVE-2019-9516 →CVE-2019-12384 →CVE-2015-9251 →CVE-2018-12536 →CVE-2019-9513 →CVE-2019-9517 →CVE-2019-10174 →CVE-2019-10247 →CVE-2019-14379 →CVE-2019-14439 →CVE-2017-5929 →CVE-2018-15756 →CVE-2019-3802 →CVE-2019-3888 →CVE-2019-5427 →CVE-2019-9512 →CVE-2019-9518 →CVE-2019-11272 →CVE-2019-9515 →CVE-2019-10184 →CVE-2019-10241 →

📋 Description

CVE-2015-9251 — jquery: Cross-site scripting via cross-domain ajax requests CVE-2017-5929 — logback: Serialization vulnerability in SocketServer and ServerSocketReceiver CVE-2017-16012 — js-jquery: XSS in responses from cross-origin ajax requests CVE-2018-11771 — apache-commons-compress: ZipArchiveInputStream.read() fails to identify correct EOF allowing for DoS via crafted zip CVE-2018-12536 — jetty: full server path revealed when using the default Error Handling CVE-2018-15756 — springframework: DoS Attack via Range Requests CVE-2019-3802 — spring-data-api: potential information disclosure through maliciously crafted example value in ExampleMatcher CVE-2019-3888 — undertow: leak credentials to log files UndertowLogger.REQUEST_LOGGER.undertowRequestFailed CVE-2019-5427 — c3p0: loading XML configuration leads to denial of service CVE-2019-9512 — HTTP/2: flood using PING frames results in unbounded memory growth CVE-2019-9513 — HTTP/2: flood using PRIORITY frames results in excessive resource consumption CVE-2019-9514 — HTTP/2: flood using HEADERS frames results in unbounded memory growth CVE-2019-9515 — HTTP/2: flood using SETTINGS frames results in unbounded memory growth CVE-2019-9516 — HTTP/2: 0-length headers lead to denial of service CVE-2019-9517 — HTTP/2: request for large response leads to denial of service CVE-2019-9518 — HTTP/2: flood using empty frames results in excessive resource consumption CVE-2019-10174 — infinispan: invokeAccessibly method from ReflectionUtil class allows to invoke private methods CVE-2019-10184 — undertow: Information leak in requests for directories without trailing slashes CVE-2019-10241 — jetty: using specially formatted URL against DefaultServlet or ResourceHandler leads to XSS conditions CVE-2019-10247 — jetty: error path information disclosure CVE-2019-11272 — spring-security-core: mishandling of user passwords allows logging in with a password of NULL CVE-2019-12384 — jackson-databind: failure to block the logback-core class from polymorphic deserialization leading to remote code execution CVE-2019-12422 — shiro: Cookie padding oracle vulnerability with default configuration CVE-2019-12814 — jackson-databind: polymorphic typing issue allows attacker to read arbitrary local files on the server via crafted JSON message. CVE-2019-14379 — jackson-databind: default typing mishandling leading to remote code execution CVE-2019-14439 — jackson-databind: Polymorphic typing issue related to logback/JNDI CVE-2019-17570 — xmlrpc: Deserialization of server-side exception from faultCause in XMLRPC error response

🎯 Affected products1

  • Red Hat Fuse 7.6.0

✅ Remediation

Before applying the update, back up your existing installation, including all applications, configuration files, databases and database settings, and so on. Installation instructions are available from the Fuse 7.6.0 product documentation page: https://access.redhat.com/documentation/en-us/red_hat_fuse/7.6/ Workaround: Information disclosure occurs when java.nio.file.InvalidPathException occurs and is handled by the default Jetty error handler. To protect against this, a custom error handler can be configured for that particular error or for a larger set of errors according to the documentation link below. Red Hat Product Security advises that production deployments on Jetty use custom error handlers to limit the information disclosed and to ensure effective logging of error conditions. http://www.eclipse.org/jetty/documentation/current/custom-error-pages.html Workaround: Red Hat Quay 3.0 uses Nginx 1.12 from Red Hat Software Collections. It will be updated once a fixed is released for Software Collections. In the meantime users of Quay can disable http/2 support in Nginx by following these instructions: 1. Copy the Nginx configuration from the quay container to the host $ docker cp 3aadf1421ba3:/quay-registry/conf/nginx/ /mnt/quay/nginx 2. Edit the Nginx configuration, removing http/2 support $ sed -i 's/http2 //g' /mnt/quay/nginx/nginx.conf 3. Restart Nginx with the new configuration mounted into the container, eg: $ docker run --restart=always -p 443:8443 -p 80:8080 --sysctl net.core.somaxconn=4096 -v /mnt/quay/config:/conf/stack:Z -v /mnt/quay/storage:/datastorage -v /mnt/quay/nginx:/quay-registry/config/nginx:Z -d quay.io/redhat/quay:v3.0.3 Workaround: The httpd version shipped with Red Hat Enterprise Linux 8 provides HTTP/2 support through mod_http2 package. While mod_http2 package is not updated, users can disable HTTP/2 support as mitigation action by executing the following steps: 1. Stop httpd service: $ systemctl stop httpd 2. Remove http/2 protocol support from configuration files: $ sed -i 's/\(h2\)\|\(h2c\)//g' <httpd_config_file> 3. Validate configuration files to make sure all syntax is valid: $ apachectl configtest 4. Restart httpd service: $ systemctl start httpd Workaround: There is no known mitigation for this issue. Workaround: The following conditions are needed for an exploit, we recommend avoiding all if possible: * Deserialization from sources you do not control * `enableDefaultTyping()` * `@JsonTypeInfo using `id.CLASS` or `id.MINIMAL_CLASS` Workaround: This vulnerability relies on jdom (org.jdom) or jdom2 (org.jdom2) being present in the application's ClassPath. Applications using jackson-databind that do not also use jdom or jdom2 are not impacted by this vulnerability. Workaround: The following conditions are needed for an exploit, we recommend avoiding all if possible * Deserialization from sources you do not control * `enableDefaultTyping()` * `@JsonTypeInfo using `id.CLASS` or `id.MINIMAL_CLASS` Workaround: There is no known mitigation other than restricting applications using the Apache XMLRPC client library from sending requests to untrusted XMLRPC servers.

🔗 References (29)