CVSS: 5.5EPSS: 1%CPEs: 4EXPL: 1CVE-2018-8026
https://notcve.org/view.php?id=CVE-2018-8026
This vulnerability in Apache Solr 6.0.0 to 6.6.4 and 7.0.0 to 7.3.1 relates to an XML external entity expansion (XXE) in Solr config files (currency.xml, enumsConfig.xml referred from schema.xml, TIKA parsecontext config file). In addition, Xinclude functionality provided in these config files is also affected in a similar way. The vulnerability can be used as XXE using file/ftp/http protocols in order to read arbitrary local files from the Solr server or the internal network. The manipulated files can be uploaded as configsets using Solr's API, allowing to exploit that vulnerability. Esta vulnerabilidad en Apache Solr, de la versión 6.0.0 a la 6.6.4 y de la versión 7.0.0 a la 7.3.1, está relacionada con una expansión XEE (XML External Entity) en los archivos de configuración de Solr (currency.xml, enumsConfig.xml referido desde schema.xml y el archivo de configuración TIKA parsecontext). • http://www.securityfocus.com/bid/104690 https://issues.apache.org/jira/browse/SOLR-12450 https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201807.mbox/%3C0cdc01d413b7%24f97ba580%24ec72f080%24%40apache.org%3E https://security.netapp.com/advisory/ntap-20190307-0002 • CWE-611: Improper Restriction of XML External Entity Reference •
CVSS: 9.8EPSS: 1%CPEs: 29EXPL: 0CVE-2017-7658 – jetty: Incorrect header handling
https://notcve.org/view.php?id=CVE-2017-7658
In Eclipse Jetty Server, versions 9.2.x and older, 9.3.x (all non HTTP/1.x configurations), and 9.4.x (all HTTP/1.x configurations), when presented with two content-lengths headers, Jetty ignored the second. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decided on the shorter length, but still passed on the longer body, then body content could be interpreted by Jetty as a pipelined request. If the intermediary was imposing authorization, the fake pipelined request would bypass that authorization. En Eclipse Jetty Server, en versiones 9.2.x y anteriores, versiones 9.3.x (todas las configuraciones que no sean HTTP/1.x) y versiones 9.4.x (todas las configuraciones HTTP/1.x), cuando se presentan con dos cabeceras content-lengths, Jetty ignora la segunda. • http://www.securityfocus.com/bid/106566 http://www.securitytracker.com/id/1041194 https://bugs.eclipse.org/bugs/show_bug.cgi?id=535669 https://lists.apache.org/thread.html/053d9ce4d579b02203db18545fee5e33f35f2932885459b74d1e4272%40%3Cissues.activemq.apache.org%3E https://lists.apache.org/thread.html/708d94141126eac03011144a971a6411fcac16d9c248d1d535a39451%40%3Csolr-user.lucene.apache.org%3E https://lists.apache.org/thread.html/9317fd092b257a0815434b116a8af8daea6e920b6673f4fd5583d5fe%40%3Ccommits.druid.apache.org%3E https://lists.apache.org/thread& • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVSS: 9.8EPSS: 0%CPEs: 27EXPL: 0CVE-2017-7657 – jetty: HTTP request smuggling
https://notcve.org/view.php?id=CVE-2017-7657
In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request. En Eclipse Jetty, en versiones 9.2.x y anteriores, versiones 9.3.x (todas las configuraciones) y versiones 9.4.x (configuración personalizada con el cumplimiento RFC2616 habilitado), los fragmentos transfer-encoding se gestionan de forma incorrecta. • http://www.securitytracker.com/id/1041194 https://access.redhat.com/errata/RHSA-2019:0910 https://bugs.eclipse.org/bugs/show_bug.cgi?id=535668 https://lists.apache.org/thread.html/053d9ce4d579b02203db18545fee5e33f35f2932885459b74d1e4272%40%3Cissues.activemq.apache.org%3E https://lists.apache.org/thread.html/708d94141126eac03011144a971a6411fcac16d9c248d1d535a39451%40%3Csolr-user.lucene.apache.org%3E https://lists.apache.org/thread.html/9317fd092b257a0815434b116a8af8daea6e920b6673f4fd5583d5fe%40%3Ccommits.druid.apache.org%3E https://lists.apache. • CWE-190: Integer Overflow or Wraparound CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVSS: 8.8EPSS: 0%CPEs: 12EXPL: 0CVE-2018-12538
https://notcve.org/view.php?id=CVE-2018-12538
In Eclipse Jetty versions 9.4.0 through 9.4.8, when using the optional Jetty provided FileSessionDataStore for persistent storage of HttpSession details, it is possible for a malicious user to access/hijack other HttpSessions and even delete unmatched HttpSessions present in the FileSystem's storage for the FileSessionDataStore. En Eclipse Jetty, desde la versión 9.4.0 hasta la 9.4.8, al emplear el FileSessionDataStore opcional provisto por Jetty para el almacenamiento persistente de detalles HttpSession, es posible que un usuario malicioso acceda/secuestre otras HttpSessions e incluso elimine HttpSessions sin coincidencias presentes en el almacenamiento FileSystem para FileSessionDataStore. • http://www.securitytracker.com/id/1041194 https://bugs.eclipse.org/bugs/show_bug.cgi?id=536018 https://lists.apache.org/thread.html/r1b103833cb5bc8466e24ff0ecc5e75b45a705334ab6a444e64e840a0%40%3Cissues.bookkeeper.apache.org%3E https://security.netapp.com/advisory/ntap-20181014-0001 https://www.oracle.com/security-alerts/cpuoct2020.html https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html • CWE-6: J2EE Misconfiguration: Insufficient Session-ID Length CWE-384: Session Fixation •
CVSS: 9.8EPSS: 4%CPEs: 18EXPL: 0CVE-2018-8014 – tomcat: Insecure defaults in CORS filter enable 'supportsCredentials' for all origins
https://notcve.org/view.php?id=CVE-2018-8014
The defaults settings for the CORS filter provided in Apache Tomcat 9.0.0.M1 to 9.0.8, 8.5.0 to 8.5.31, 8.0.0.RC1 to 8.0.52, 7.0.41 to 7.0.88 are insecure and enable 'supportsCredentials' for all origins. It is expected that users of the CORS filter will have configured it appropriately for their environment rather than using it in the default configuration. Therefore, it is expected that most users will not be impacted by this issue. Las opciones por defecto para el filtro CORS proporcionado en Apache Tomcat 9.0.0.M1 a 9.0.8, 8.5.0 a 8.5.31, 8.0.0.RC1 a 8.0.52 y 7.0.41 a 7.0.88 son inseguras y permiten "supportsCredentials" para todos los orígenes. Se espera que los usuarios del filtro CORS lo tengan configurado de forma adecuada para su entorno, en lugar de emplearlo con su configuración por defecto. • http://tomcat.apache.org/security-7.html http://tomcat.apache.org/security-8.html http://tomcat.apache.org/security-9.html http://www.oracle.com/technetwork/security-advisory/cpuoct2018-4428296.html http://www.securityfocus.com/bid/104203 http://www.securitytracker.com/id/1040998 http://www.securitytracker.com/id/1041888 https://access.redhat.com/errata/RHSA-2018:2469 https://access.redhat.com/errata/RHSA-2018:2470 https://access.redhat.com/errata/RHSA-2018:3768 https://a • CWE-284: Improper Access Control CWE-1188: Initialization of a Resource with an Insecure Default •