A flaw was found in Apache Commons Compress versions 1.11 to 1.15. A specially crafted ZIP archive can be used to cause an infinite loop inside of Apache Commons Compress' extra field parser used by the ZipFile and ZipArchiveInputStream classes in versions 1.11 to 1.15. This can be used to mount a denial of service attack against services that use Compress' zip package. Upstream patch: https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=blobdiff;f=src/main/java/org/apache/commons/compress/archivers/zip/X0017_StrongEncryptionHeader.java;h=acc3b22346b49845e85b5ef27a5814b69e834139;hp=0feb9c98cc622cde1defa3bbd268ef82b4ae5c18;hb=2a2f1dc48e22a34ddb72321a4db211da91aa933b;hpb=dcb0486fb4cb2b6592c04d6ec2edbd3f690df5f2 Upstream issue: https://issues.apache.org/jira/browse/COMPRESS-432
Created apache-commons-compress tracking bugs for this issue: Affects: fedora-all [bug 1557543]
External References: https://commons.apache.org/proper/commons-compress/security-reports.html
Statement: This issue affects the versions of lucene4 as shipped with Red Hat Enterprise Satellite 6.0 and 6.1. Red Hat Satellite 6.2 and later do not include the lucene4 component and are not affected.
apache-commons-compress-1.13-3.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
apache-commons-compress-1.14-3.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.
RHMAP has a dependency on commons-compress because it's required by log4j-core. Log4j-core only uses commons-compress for compression of log files, and doesn't provide any decompression functionality. Therefore log4j-core and RHMAP are not affected by this flaw.