RHSA-2020:2333HighCVSS 8.8

Red Hat Security Advisory: EAP Continuous Delivery Technical Preview Release 19 security update

Published
May 28, 2020
Last Modified
August 4, 2026

🔗 CVE IDs covered (33)

📋 Description

CVE-2019-0205 — thrift: Endless loop when feed with specific input data CVE-2019-0210 — thrift: Out-of-bounds read related to TJSONProtocol or TSimpleJSONProtocol CVE-2019-10086 — apache-commons-beanutils: does not suppresses the class property in PropertyUtilsBean by default CVE-2019-10174 — infinispan: invokeAccessibly method from ReflectionUtil class allows to invoke private methods CVE-2019-12419 — cxf: OpenId Connect token service does not properly validate the clientId CVE-2019-12423 — cxf: OpenId Connect token service does not properly validate the clientId CVE-2019-14540 — jackson-databind: Serialization gadgets in com.zaxxer.hikari.HikariConfig CVE-2019-14887 — wildfly: The 'enabled-protocols' value in legacy security is not respected if OpenSSL security provider is in use CVE-2019-14888 — undertow: possible Denial Of Service (DOS) in Undertow HTTP server listening on HTTPS CVE-2019-14892 — jackson-databind: Serialization gadgets in classes of the commons-configuration package CVE-2019-14893 — jackson-databind: Serialization gadgets in classes of the xalan package CVE-2019-16335 — jackson-databind: Serialization gadgets in com.zaxxer.hikari.HikariDataSource CVE-2019-16869 — netty: HTTP request smuggling by mishandled whitespace before the colon in HTTP headers CVE-2019-16942 — jackson-databind: Serialization gadgets in org.apache.commons.dbcp.datasources.* CVE-2019-16943 — jackson-databind: Serialization gadgets in com.p6spy.engine.spy.P6DataSource CVE-2019-17267 — jackson-databind: Serialization gadgets in classes of the ehcache package CVE-2019-17531 — jackson-databind: Serialization gadgets in org.apache.log4j.receivers.db.* CVE-2019-17573 — cxf: reflected XSS in the services listing page CVE-2019-20330 — jackson-databind: lacks certain net.sf.ehcache blocking CVE-2019-20444 — netty: HTTP request smuggling CVE-2019-20445 — netty: HttpObjectDecoder.java allows Content-Length header to accompanied by second Content-Length header CVE-2020-1695 — resteasy: Improper validation of response header in MediaTypeHeaderDelegate.java class CVE-2020-1732 — Soteria: security identity corruption across concurrent threads CVE-2020-1745 — undertow: AJP File Read/Inclusion Vulnerability CVE-2020-7238 — netty: HTTP Request Smuggling due to Transfer-Encoding whitespace mishandling CVE-2020-9547 — jackson-databind: Serialization gadgets in ibatis-sqlmap CVE-2020-10672 — jackson-databind: mishandles the interaction between serialization gadgets and typing which could result in remote command execution CVE-2020-10688 — RESTEasy: RESTEASY003870 exception in RESTEasy can lead to a reflected XSS attack CVE-2020-10968 — jackson-databind: Serialization gadgets in org.aoju.bus.proxy.provider.*.RmiProvider CVE-2020-10969 — jackson-databind: Serialization gadgets in javax.swing.JEditorPane CVE-2020-11111 — jackson-databind: Serialization gadgets in org.apache.activemq.jms.pool.XaPooledConnectionFactory CVE-2020-11112 — jackson-databind: Serialization gadgets in org.apache.commons.proxy.provider.remoting.RmiProvider CVE-2020-11113 — jackson-databind: Serialization gadgets in org.apache.openjpa.ee.WASRegistryManagedRuntime

🎯 Affected products1

  • EAP-CD 19 Tech Preview

✅ Remediation

Before applying this update, back up your existing Red Hat JBoss Enterprise Application Platform installation and deployed applications. You must restart the JBoss server process for the update to take effect. The References section of this erratum contains a download link (you must log in to download the update) Workaround: There is no currently known mitigation for this flaw. Workaround: There is no known mitigation for this issue. Workaround: This vulnerability relies on com.zaxxer.hikari.HikariConfig being present in the application's ClassPath. Hikari is not packaged as an RPM for Red Hat Enterprise Linux or Red Hat Software Collections. Applications using jackson-databind that do not also use com.zaxxer.hikari are not impacted by this vulnerability. A mitigation to this class of problem in jackson-databind is to not trigger polymorphic desrialization globally by using: objectMapper.enableDefaultTyping() and rather use @JsonTypeInfo on the class property to explicitly define the type information. For more information on this issue please refer to https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true Workaround: Avoid using an OpenSSL security provider and instead use the default configuration or regular JSSE provider with 'TLS'. Workaround: Enable HTTP2 (enable-http2="true") in the undertow's HTTPS settings. 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 com.zaxxer.hikari.HikariDataSource being present in the application's ClassPath. Hikari is not packaged as an RPM for Red Hat Enterprise Linux or Red Hat Software Collections. Applications using jackson-databind that do not also use com.zaxxer.hikari are not impacted by this vulnerability. A mitigation to this class of problem in jackson-databind is to not trigger polymorphic desrialization globally by using: objectMapper.enableDefaultTyping() and rather use @JsonTypeInfo on the class property to explicitly define the type information. For more information on this issue please refer to https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true Workaround: * Use HTTP/2 instead (clear boundaries between requests) * Disable reuse of backend connections eg. ```http-reuse never``` in HAProxy or whatever equivalent LB settings Workaround: Mitigate this flaw by disabling the service listing altogether; via setting the "hide-service-list-page" servlet parameter to "true". 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: Please refer to the Red Hat knowledgebase article: https://access.redhat.com/solutions/4851251

🔗 References (47)