WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕Vendor org.apache.solr✕
Overview 4 matches · 0 protected · 2 exploited · 0 CISA KEV · 3 EPSS ≥ 0.5
4matches 0protected0.0% 2exploited50.0% 0CISA KEV0.0% 3EPSS ≥ 0.575.0%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 4 100.0% No exploit published 0 0.0% Outside Waratek scope 0 0.0% Not applicable 0 0.0% Withdrawn CVE 0 0.0%
Critical 2 50.0% High 1 25.0% Medium 1 25.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 4 100.0% not established 0 0.0% unrecorded 0 0.0%
4 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2024-45216 Critical 2024-10-16 Mitigation candidate Exploited 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.
CVE-2023-50386 High 2024-02-09 Mitigation candidate Exploited Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1. In the affected versions, Solr ConfigSets accepted Java jar and class files to be uploaded through the ConfigSets API. When backing up Solr Collections, these configSet files would be saved to disk when using the LocalFileSystemRepository (the default for backups). If the backup was saved to a directory that Solr uses in its ClassPath/ClassLoaders, then the jar and class files would be available to use with any ConfigSet, trusted or untrusted. When Solr is run in a secure way (Authorization enabled), as is strongly suggested, this vulnerability is limited to extending the Backup permissions with the ability to add libraries. Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue. In these versions, the following protections have been added: * Users are no longer able to upload files to a configSet that could be executed via a Java ClassLoader. * The Backup API restricts saving backups to directories that are used in the ClassLoader.
CVE-2023-50290 Medium 2024-01-15 Mitigation candidate Working exploit published Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Solr. The Solr Metrics API publishes all unprotected environment variables available to each Apache Solr instance. Users are able to specify which environment variables to hide, however, the default list is designed to work for known secret Java system properties. Environment variables cannot be strictly defined in Solr, like Java system properties can be, and may be set for the entire host, unlike Java system properties which are set per-Java-proccess. The Solr Metrics API is protected by the "metrics-read" permission. Therefore, Solr Clouds with Authorization setup will only be vulnerable via users with the "metrics-read" permission. This issue affects Apache Solr: from 9.0.0 before 9.3.0. Users are recommended to upgrade to version 9.3.0 or later, in which environment variables are not published via the Metrics API.
CVE-2019-12409 Critical 2019-11-18 Mitigation candidate Proof of concept only The 8.1.1 and 8.2.0 releases of Apache Solr contain an insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration option in the default solr.in.sh configuration file shipping with Solr. If you use the default solr.in.sh file from the affected releases, then JMX monitoring will be enabled and exposed on RMI_PORT (default=18983), without any authentication. If this port is opened for inbound traffic in your firewall, then anyone with network access to your Solr nodes will be able to access JMX, which may in turn allow them to upload malicious code for execution on the Solr server.