Page 3 of 41 results (0.007 seconds)

CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0

When starting Apache Solr versions prior to 8.8.2, configured with the SaslZkACLProvider or VMParamsAllAndReadonlyDigestZkACLProvider and no existing security.json znode, if the optional read-only user is configured then Solr would not treat that node as a sensitive path and would allow it to be readable. Additionally, with any ZkACLProvider, if the security.json is already present, Solr will not automatically update the ACLs. Cuando se inicia Apache Solr versiones anteriores a 8.8.2, configuradas con la función SaslZkACLProvider o VMParamsAllAndReadonlyDigestZkACLProvider y ningún znode security.json existente, si el usuario de solo lectura opcional está configurado, Solr no trataría ese nodo como una ruta confidencial y le permitiría ser legible. Además, con cualquier ZkACLProvider, si el archivo security.json ya está presente, Solr no actualizará automáticamente las ACL • https://lists.apache.org/thread.html/r1171f6417eeb6d5e1206d53e2b2ff2d6ee14026f8b595ef7d8a33b79%40%3Coak-issues.jackrabbit.apache.org%3E https://lists.apache.org/thread.html/r1e92a2eff6c47a65c4a6e95e809a9707181de76f8062403a0bea1012%40%3Coak-issues.jackrabbit.apache.org%3E https://lists.apache.org/thread.html/r51b29ff62060b67bc9999ded5e252b36b09311fe5a02d27f6de3e4d3%40%3Coak-issues.jackrabbit.apache.org%3E https://lists.apache.org/thread.html/r536da4c4e4e406f7843461cc754a3d0a3fe575aa576e2b71a9cd57d0%40%3Cannounce.apache.org%3E https://lists.apache.org/thread.html/r7151081abab92a827a607205c4260b0 • CWE-522: Insufficiently Protected Credentials •

CVSS: 9.8EPSS: 94%CPEs: 1EXPL: 2

The ReplicationHandler (normally registered at "/replication" under a Solr core) in Apache Solr has a "masterUrl" (also "leaderUrl" alias) parameter that is used to designate another ReplicationHandler on another Solr core to replicate index data into the local core. To prevent a SSRF vulnerability, Solr ought to check these parameters against a similar configuration it uses for the "shards" parameter. Prior to this bug getting fixed, it did not. This problem affects essentially all Solr versions prior to it getting fixed in 8.8.2. La función ReplicationHandler (normalmente registrado en "/replication" bajo un core Solr) en Apache Solr presenta un parámetro "masterUrl" (también se conoce como "leaderUrl") que es usada para designar otro ReplicationHandler en otro core Solr para replicar datos de índice en el core local . • https://github.com/murataydemir/CVE-2021-27905 https://github.com/pdelteil/CVE-2021-27905.POC https://lists.apache.org/thread.html/r0ddc3a82bd7523b1453cb7a5e09eb5559517145425074a42eb326b10%40%3Cannounce.apache.org%3E https://lists.apache.org/thread.html/r140128dc6bb4f4e0b6a39e962c7ca25a8cbc8e48ed766176c931fccc%40%3Cusers.solr.apache.org%3E https://lists.apache.org/thread.html/r3da74965aba2b5f5744b7289ad447306eeb2940c872801819faa9314%40%3Cusers.solr.apache.org%3E https://lists.apache.org/thread.html/r6ccec7fc54d82591b23c143f1f6a6e38f6e03e75db70870e4cb14a1a%40%3Ccommits.ofbiz • CWE-918: Server-Side Request Forgery (SSRF) •

CVSS: 4.0EPSS: 0%CPEs: 33EXPL: 1

In Eclipse Jetty 9.4.32 to 9.4.38, 10.0.0.beta2 to 10.0.1, and 11.0.0.beta2 to 11.0.1, if a user uses a webapps directory that is a symlink, the contents of the webapps directory is deployed as a static webapp, inadvertently serving the webapps themselves and anything else that might be in that directory. En Eclipse Jetty versiones 9.4.32 hasta 9.4.38, versiones 10.0.0.beta2 hasta 10.0.1 y versiones 11.0.0.beta2 hasta 11.0.1, si un usuario usa un directorio de aplicaciones web que es un enlace simbólico, el contenido del directorio de aplicaciones web se implementa como una aplicación web estática, sin darse cuenta, sirviendo las aplicaciones web en sí y cualquier otra cosa que pueda estar en ese directorio. If the ${jetty.base} directory or the ${jetty.base}/webapps directory is a symlink the contents of the ${jetty.base}/webapps directory may be deployed as a static web application, exposing the content of the directory for download. The highest threat from this vulnerability is to data confidentiality. • https://github.com/eclipse/jetty.project/security/advisories/GHSA-j6qj-j888-vvgq https://lists.apache.org/thread.html/r0841b06b48324cfc81325de3c05a92e53f997185f9d71ff47734d961%40%3Cissues.solr.apache.org%3E https://lists.apache.org/thread.html/r111f1ce28b133a8090ca4f809a1bdf18a777426fc058dc3a16c39c66%40%3Cissues.solr.apache.org%3E https://lists.apache.org/thread.html/r2ea2f0541121f17e470a0184843720046c59d4bde6d42bf5ca6fad81%40%3Cissues.solr.apache.org%3E https://lists.apache.org/thread.html/r4a66bfbf62281e31bc1345ebecbfd96f35199eecd77bfe4e903e906f%40%3Cissues.ignite.apache.org%3 • CWE-59: Improper Link Resolution Before File Access ('Link Following') CWE-200: Exposure of Sensitive Information to an Unauthorized Actor •

CVSS: 5.3EPSS: 2%CPEs: 23EXPL: 2

In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of “quality” (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values. En Eclipse Jetty versiones 9.4.6.v20170531 hasta 9.4.36.v20210114 (inclusive), versiones 10.0.0 y 11.0.0, cuando Jetty maneja una petición que contiene múltiples encabezados Accept con una gran cantidad de parámetros “quality” (es decir, q), el servidor puede entrar en un estado de denegación de servicio (DoS) debido al alto uso de CPU procesando esos valores de calidad, resultando en minutos de tiempo de CPU agotados procesando esos valores de calidad • https://github.com/motikan2010/CVE-2020-27223 https://github.com/ttestoo/Jetty-CVE-2020-27223 https://bugs.eclipse.org/bugs/show_bug.cgi?id=571128 https://github.com/eclipse/jetty.project/security/advisories/GHSA-m394-8rww-3jr7 https://lists.apache.org/thread.html/r068dfd35ce2193f6af28b74ff29ab148c2b2cacb235995576f5bea78%40%3Cissues.solr.apache.org%3E https://lists.apache.org/thread.html/r07aedcb1ece62969c406cb84c8f0e22cec7e42cdc272f3176e473320%40%3Cusers.solr.apache.org%3E https://lists.apache.org/thread.html/r0b639bd9bfaea2650221 • CWE-400: Uncontrolled Resource Consumption CWE-407: Inefficient Algorithmic Complexity •

CVSS: 8.8EPSS: 1%CPEs: 7EXPL: 0

In Apache Hadoop 3.2.0 to 3.2.1, 3.0.0-alpha1 to 3.1.3, and 2.0.0-alpha to 2.10.0, WebHDFS client might send SPNEGO authorization header to remote URL without proper verification. En Apache Hadoop versiones 3.2.0 hasta 3.2.1, versiones 3.0.0-alpha1 hasta 3.1.3 y versiones 2.0.0-alpha hasta 2.10.0, el cliente WebHDFS puede enviar el encabezado de autorización SPNEGO hacia una URL remota sin la comprobación apropiada A flaw was found in Apache hadoop. The WebHDFS client can send a SPNEGO authorization header to a remote URL without proper verification which could lead to an access restriction bypass. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability. • https://lists.apache.org/thread.html/r0a534f1cde7555f7208e9f9b791c1ab396d215eaaef283b3a9153429%40%3Ccommits.druid.apache.org%3E https://lists.apache.org/thread.html/r49c9ab444ab1107c6a8be8a0d66602dec32a16d96c2631fec8d309fb%40%3Cissues.solr.apache.org%3E https://lists.apache.org/thread.html/r4a57de5215494c35c8304cf114be75d42df7abc6c0c54bf163c3e370%40%3Cissues.solr.apache.org%3E https://lists.apache.org/thread.html/r513758942356ccd0d14538ba18a09903fc72716d74be1cb727ea91ff%40%3Cgeneral.hadoop.apache.org%3E https://lists.apache.org/thread.html/r6341f2a468ced8872a71997aa1786ce036242413484f0fa68dc9ca02% • CWE-863: Incorrect Authorization •