CVSS: 8.1EPSS: 0%CPEs: 2EXPL: 0CVE-2024-45217 – Apache Solr: ConfigSets created during a backup restore command are trusted implicitly
https://notcve.org/view.php?id=CVE-2024-45217
Insecure Default Initialization of Resource vulnerability in Apache Solr. New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give it a new name, are created without setting the "trusted" metadata. ConfigSets that do not contain the flag are trusted implicitly if the metadata is missing, therefore this leads to "trusted" ConfigSets that may not have been created with an Authenticated request. "trusted" ConfigSets are able to load custom code into classloaders, therefore the flag is supposed to only be set when the request that uploads the ConfigSet is Authenticated & Authorized. This issue affects Apache Solr: from 6.6.0 before 8.11.4, from 9.0.0 before 9.7.0. This issue does not affect Solr instances that are secured via Authentication/Authorization. Users are primarily recommended to use Authentication and Authorization when running Solr. However, upgrading to version 9.7.0, or 8.11.4 will mitigate this issue otherwise. Vulnerabilidad de inicialización predeterminada insegura de recursos en Apache Solr. Los nuevos ConfigSets que se crean mediante un comando de restauración, que copian un configSet de la copia de seguridad y le dan un nuevo nombre, se crean sin configurar los metadatos "confiables". • https://solr.apache.org/security.html#cve-2024-45217-apache-solr-configsets-created-during-a-backup-restore-command-are-trusted-implicitly • CWE-1188: Initialization of a Resource with an Insecure Default •
CVSS: 9.8EPSS: 0%CPEs: 2EXPL: 0CVE-2024-45216 – Apache Solr: Authentication bypass possible using a fake URL Path ending
https://notcve.org/view.php?id=CVE-2024-45216
Improper Authentication vulnerability in Apache Solr. Solr instances using the PKIAuthenticationPlugin, which is enabled by default when Solr Authentication is used, are vulnerable to Authentication bypass. A fake ending at the end of any Solr API URL path, will allow requests to skip Authentication while maintaining the API contract with the original URL Path. This fake ending looks like an unprotected API path, however it is stripped off internally after authentication but before API routing. This issue affects Apache Solr: from 5.3.0 before 8.11.4, from 9.0.0 before 9.7.0. Users are recommended to upgrade to version 9.7.0, or 8.11.4, which fix the issue. Vulnerabilidad de autenticación incorrecta en Apache Solr. Las instancias de Solr que utilizan PKIAuthenticationPlugin, que está habilitado de forma predeterminada cuando se utiliza la autenticación de Solr, son vulnerables a la omisión de la autenticación. Una terminación falsa al final de cualquier ruta de URL de la API de Solr permitirá que las solicitudes omitan la autenticación mientras se mantiene el contrato de API con la ruta de URL original. Esta terminación falsa parece una ruta de API desprotegida, sin embargo, se elimina internamente después de la autenticación pero antes del enrutamiento de API. • https://solr.apache.org/security.html#cve-2024-45216-apache-solr-authentication-bypass-possible-using-a-fake-url-path-ending • CWE-287: Improper Authentication CWE-863: Incorrect Authorization •
CVSS: 6.5EPSS: 0%CPEs: 1EXPL: 0CVE-2024-31391 – Apache Solr Operator: Solr-Operator liveness and readiness probes may leak basic auth credentials
https://notcve.org/view.php?id=CVE-2024-31391
Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator. This issue affects all versions of the Apache Solr Operator from 0.3.0 through 0.8.0. When asked to bootstrap Solr security, the operator will enable basic authentication and create several accounts for accessing Solr: including the "solr" and "admin" accounts for use by end-users, and a "k8s-oper" account which the operator uses for its own requests to Solr. One common source of these operator requests is healthchecks: liveness, readiness, and startup probes are all used to determine Solr's health and ability to receive traffic. By default, the operator configures the Solr APIs used for these probes to be exempt from authentication, but users may specifically request that authentication be required on probe endpoints as well. Whenever one of these probes would fail, if authentication was in use, the Solr Operator would create a Kubernetes "event" containing the username and password of the "k8s-oper" account. Within the affected version range, this vulnerability affects any solrcloud resource which (1) bootstrapped security through use of the `.solrOptions.security.authenticationType=basic` option, and (2) required authentication be used on probes by setting `.solrOptions.security.probesRequireAuth=true`. Users are recommended to upgrade to Solr Operator version 0.8.1, which fixes this issue by ensuring that probes no longer print the credentials used for Solr requests. Users may also mitigate the vulnerability by disabling authentication on their healthcheck probes using the setting `.solrOptions.security.probesRequireAuth=false`. Vulnerabilidad de inserción de información confidencial en un archivo de registro en el operador Apache Solr. Este problema afecta a todas las versiones del operador Apache Solr desde la 0.3.0 hasta la 0.8.0. Cuando se le solicite iniciar la seguridad de Solr, el operador habilitará la autenticación básica y creará varias cuentas para acceder a Solr: incluidas las cuentas "solr" y "admin" para uso de los usuarios finales, y una cuenta "k8s-oper" que utiliza el operador. para sus propias solicitudes a Solr. • http://www.openwall.com/lists/oss-security/2024/04/12/7 https://lists.apache.org/thread/w7011s78lzywzwyszvy4d8zm99ybt8c7 • CWE-532: Insertion of Sensitive Information into Log File •
CVSS: 7.5EPSS: 0%CPEs: 2EXPL: 0CVE-2023-50291 – Apache Solr: System Property redaction logic inconsistency can lead to leaked passwords
https://notcve.org/view.php?id=CVE-2023-50291
Insufficiently Protected Credentials vulnerability in Apache Solr. This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.3.0. One of the two endpoints that publishes the Solr process' Java system properties, /admin/info/properties, was only setup to hide system properties that had "password" contained in the name. There are a number of sensitive system properties, such as "basicauth" and "aws.secretKey" do not contain "password", thus their values were published via the "/admin/info/properties" endpoint. This endpoint populates the list of System Properties on the home screen of the Solr Admin page, making the exposed credentials visible in the UI. This /admin/info/properties endpoint is protected under the "config-read" permission. Therefore, Solr Clouds with Authorization enabled will only be vulnerable through logged-in users that have the "config-read" permission. Users are recommended to upgrade to version 9.3.0 or 8.11.3, which fixes the issue. A single option now controls hiding Java system property for all endpoints, "-Dsolr.hiddenSysProps". By default all known sensitive properties are hidden (including "-Dbasicauth"), as well as any property with a name containing "secret" or "password". Users who cannot upgrade can also use the following Java system property to fix the issue: '-Dsolr.redaction.system.pattern=.*(password|secret|basicauth).*' Vulnerabilidad de credenciales insuficientemente protegidas en Apache Solr. Este problema afecta a Apache Solr: desde 6.0.0 hasta 8.11.2, desde 9.0.0 antes de 9.3.0. Uno de los dos endpoints que publica las propiedades del sistema Java del proceso Solr, /admin/info/properties, solo se configuró para ocultar las propiedades del sistema que tenían "password" en el nombre. Hay una serie de propiedades confidenciales del sistema, como "basicauth" y "aws.secretKey" que no contienen "password", por lo que sus valores se publicaron a través del endpoint "/admin/info/properties". • http://www.openwall.com/lists/oss-security/2024/02/09/4 https://solr.apache.org/security.html#cve-2023-50291-apache-solr-can-leak-certain-passwords-due-to-system-property-redaction-logic-inconsistencies • CWE-522: Insufficiently Protected Credentials •
CVSS: 7.5EPSS: 0%CPEs: 2EXPL: 0CVE-2023-50292 – Apache Solr: Solr Schema Designer blindly "trusts" all configsets, possibly leading to RCE by unauthenticated users
https://notcve.org/view.php?id=CVE-2023-50292
Incorrect Permission Assignment for Critical Resource, Improper Control of Dynamically-Managed Code Resources vulnerability in Apache Solr. This issue affects Apache Solr: from 8.10.0 through 8.11.2, from 9.0.0 before 9.3.0. The Schema Designer was introduced to allow users to more easily configure and test new Schemas and configSets. However, when the feature was created, the "trust" (authentication) of these configSets was not considered. External library loading is only available to configSets that are "trusted" (created by authenticated users), thus non-authenticated users are unable to perform Remote Code Execution. Since the Schema Designer loaded configSets without taking their "trust" into account, configSets that were created by unauthenticated users were allowed to load external libraries when used in the Schema Designer. Users are recommended to upgrade to version 9.3.0, which fixes the issue. Asignación de permisos incorrecta para recursos críticos, vulnerabilidad de control inadecuado de recursos de código administrados dinámicamente en Apache Solr. Este problema afecta a Apache Solr: desde 8.10.0 hasta 8.11.2, desde 9.0.0 antes de 9.3.0. Schema Designer se introdujo para permitir a los usuarios configurar y probar más fácilmente nuevos esquemas y conjuntos de configuración. Sin embargo, cuando se creó la función, no se consideró la "confianza" (autenticación) de estos conjuntos de configuración. • http://www.openwall.com/lists/oss-security/2024/02/09/3 https://solr.apache.org/security.html#cve-2023-50298-apache-solr-can-expose-zookeeper-credentials-via-streaming-expressions • CWE-732: Incorrect Permission Assignment for Critical Resource •