Full history of Apache Solr security advisories. Subscribe to the security ATOM feed to be notified of new advisories.
Severity moderate
Description Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr's "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components. Only deployments that meet all of the following criteria are impacted by this vulnerability:
Mitigation
Users can mitigate this vulnerability by ensuring that their RuleBasedAuthorizationPlugin configuration specifies the "all" pre-defined permission and associates the permission with an "admin" or other privileged role. Users can also upgrade to a Solr version outside of the impacted range, such as the recently released Solr 9.10.1.
Credit monkeontheroof (reporter)
References
Severity moderate
Description
The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr's "allowPaths" security setting. These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem. On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes.
Solr deployments are subject to this vulnerability if they meet the following criteria:
Mitigation
Users can mitigate this by enabling Solr's RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores. Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue.
Credit Damon Toey (reporter)
References
Severity
High
Versions Affected
Description
Solr's extraction module (SolrCell) uses Apache Tika to extract content from PDF files. A vulnerability in Tika allows attackers to submit specially crafted PDFs that can read files from the server.
Who is affected:
Who is NOT affected:
Impact:
Mitigation
Disable XFA form parsing in PDFs by configuring a parseContext file.
Step 1: Create or edit parseContext.xml in your configset's conf/ directory:
<?xml version="1.0" ?>
<entries>
<entry class="org.apache.tika.parser.pdf.PDFParserConfig" impl="org.apache.tika.parser.pdf.PDFParserConfig">
<property name="extractAcroFormContent" value="false"/>
</entry>
</entries>
Step 2: Reference this file in your extraction handler in solrconfig.xml:
<requestHandler name="/update/extract" class="org.apache.solr.handler.extraction.ExtractingRequestHandler">
<str name="parseContext.config">parseContext.xml</str>
</requestHandler>
Step 3: Reload your collection or restart Solr.
Note: Solr 9.10.1 and later (once available) will include this mitigation by default.
Credit
Apache Tika Security Team (vulnerability discovery)
References
Severity moderate
Versions Affected
Description
Relative Path Traversal vulnerability in Apache Solr.
Solr instances running on Windows are vulnerable to arbitrary filepath write-access, due to a lack of input-sanitation in the "configset upload" API. Commonly known as a "zipslip", maliciously constructed ZIP files can use relative filepaths to write data to unanticipated parts of the filesystem.
This issue affects Apache Solr: from 6.6 through 9.7.0.
Mitigation
Users are recommended to upgrade to version 9.8.0, which fixes the issue. Users unable to upgrade may also safely prevent the issue by using Solr's "Rule-Based Authentication Plugin" to restrict access to the configset upload API, so that it can only be accessed by a trusted set of administrators/users.
Credit rry (reporter)
References JIRA - SOLR-17543 CVE - CVE-2024-52012
Severity moderate
Versions Affected
Description
Core creation allows users to replace "trusted" configset files with arbitrary configuration
Solr instances that (1) use the "FileSystemConfigSetService" component (the default in "standalone" or "user-managed" mode), and (2) are running without authentication and authorization are vulnerable to a sort of privilege escalation wherein individual "trusted" configset files can be ignored in favor of potentially-untrusted replacements available elsewhere on the filesystem. These replacement config files are treated as "trusted" and can use "
This issue affects all Apache Solr versions up through Solr 9.7.
Mitigation
Users can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from "FileSystemConfigSetService"). Users are also recommended to upgrade to Solr 9.8.0, which mitigates this issue by disabling use of "
Credit pwn null (reporter)
References JIRA - SOLR-16781 CVE - CVE-2025-24814
Severity:
Critical
Versions Affected:
Description:
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.
Mitigation:
Users are recommended to upgrade to version 9.7.0, or 8.11.4, which fix the issue.
Credit: Liu Huajin (reporter)
References:
JIRA - SOLR-17417
CVE - CVE-2024-45216
Severity:
Moderate
Versions Affected:
Description:
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.
Mitigation:
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.
Credit: Liu Huajin (reporter)
References:
JIRA - SOLR-17418
CVE - CVE-2024-45217
Severity:
Moderate
Versions Affected:
Solr Operator 0.3.0 to 0.8.0
Description: Insertion of Sensitive Information into Log File vulnerability in the Apache Solr Operator.
The Solr sked 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.
Mitigation:
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.
References:
JIRA - SOLR-17216
CVE - CVE-2024-31391
Severity:
Moderate
Versions Affected:
Description:
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).*"
Mitigation:
Users are recommended to upgrade to version 8.11.3, 9.3.0 or later, which has consistent systemProperty redaction logic.
Credit: Michael Taggart (reporter)
References:
JIRA - SOLR-16809
CVE - CVE-2023-50291
Severity:
Moderate
Versions Affected:
Description:
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.
Mitigation:
Users are recommended to upgrade to version 8.11.3, 9.3.0 or later.
Credit: Skay (reporter)
References:
JIRA - SOLR-16777
CVE - CVE-2023-50292
Severity:
Low
Versions Affected:
Description:
Exposure of Sensitive Information to an Unauthorized Actor 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.
Solr Streaming Expressions allows users to extract data from other Solr Clouds, using a "zkHost" parameter. When original SolrCloud is setup to use ZooKeeper credentials and ACLs, they will be sent to whatever "zkHost" the user provides. An attacker could setup a server to mock ZooKeeper, that accepts ZooKeeper requests with credentials and ACLs and extracts the sensitive information, then send a streaming expression using the mock server's address in "zkHost". Streaming Expressions are exposed via the "/streaming" handler, with "read" permissions.
Mitigation:
Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue.
From these versions on, only zkHost values that have the same server address (regardless of chroot), will use the given ZooKeeper credentials and ACLs when connecting.
Credit: Qing Xu (reporter)
References:
JIRA - SOLR-17098
CVE - CVE-2023-50298
Severity:
Moderate
Versions Affected:
Description:
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.
Mitigation:
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:
Credit: L3yx (reporter)
References:
JIRA - SOLR-16949
CVE - CVE-2023-50386
Severity:
Important
Versions Affected:
Solr 9.0 to 9.2.1
Description:
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-process.
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.
Mitigation:
Users are recommended to upgrade to version 9.3.0 or later, in which environment variables are not published via the Metrics API.
References:
JIRA - SOLR-15233
CVE - CVE-2023-50290
Versions Affected:
Solr 6.5 to 8.11.2
Solr 9.0
Description:
Apache Calcite has a vulnerability, CVE-2022-39135, that is exploitable in Apache Solr in SolrCloud mode. If an untrusted user can supply SQL queries to Solr’s “/sql” handler (even indirectly via proxies / other apps), then the user could perform an XML External Entity (XXE) attack. This might have been exposed by some deployers of Solr in order for internal analysts to use JDBC based tooling, but would have unlikely been granted to wider audiences.
Impact:
An XXE attack may lead to the disclosure of confidential data, denial of service, server side request forgery (SSRF), port scanning from the Solr node, and other system impacts.
Mitigation:
Most Solr installations don’t make use of the SQL functionality. For such users, the standard Solr security advice of using a firewall should be adequate. Nonetheless, the functionality can be disabled. As of Solr 9, it has been modularized and thus became opt-in, so nothing is needed for Solr 9 users that don’t use it. Users not using SolrCloud can’t use the functionality at all. For other users that wish to disable it, you must register a request handler that masks the underlying functionality in solrconfig.xml like so:
<requestHandler name="/sql" class="solr.NotFoundRequestHandler"/>
Users needing this SQL functionality are forced to upgrade to Solr 9.1. If Solr 8.11.3 is released, then it will be an option as well. Simply replacing Calcite and other JAR files may mostly work but could fail depending on the particulars of the query. Users interested in this or in patching their own versions of Solr should examine SOLR-16421 for a source patch.
Credit:
Andreas Hubold at CoreMedia GmbH
References:
JIRA - SOLR-16421
CVE - CVE-2022-39135
Severity:
Moderate
Versions Affected:
All versions prior to 8.11.1. Affected platforms: Windows.
Description:
An Improper Input Validation vulnerability in DataImportHandler of Apache Solr allows an attacker to provide a Windows UNC path resulting in an SMB network call being made from the Solr host to another host on the network. If the attacker has wider access to the network, this may lead to SMB attacks, which may result in:
This issue affects all Apache Solr versions prior to 8.11.1. This issue only affects Windows.
Mitigation:
Upgrade to Solr 8.11.1, and/or ensure only trusted clients can make requests to Solr's DataImport handler.
Credit:
Apache Solr would like to thank LaiHan of Nsfocus security team for reporting the issue
References:
Jira issue SOLR-15826
Severity: Critical
Versions Affected: 7.4.0 to 7.7.3, 8.0.0 to 8.11.0
Description: Apache Solr releases prior to 8.11.1 were using a bundled version of the Apache Log4J library vulnerable to RCE. For full impact and additional detail consult the Log4J security page.
Apache Solr releases prior to 7.4 (i.e. Solr 5, Solr 6, and Solr 7 through 7.3) use Log4J 1.2.17 which may be vulnerable for installations using non-default logging configurations that include the JMS Appender, see https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126 for discussion.
Solr's Prometheus Exporter uses Log4J as well but it does not log user input or data, so we don't see a risk there.
Solr is not vulnerable to the followup CVE-2021-45046 and CVE-2021-45105. A listing of these and other CVEs with some justifications are listed in Solr's wiki: https://cwiki.apache.org/confluence/display/SOLR/SolrSecurity#SolrSecurity-SolrandVulnerabilityScanningTools
Mitigation: Any of the following are enough to prevent this vulnerability for Solr servers:
Solr 8.11.1 or greater (when available), which will include an updated version (>= 2.16.0) of the Log4J dependency.solr.in.sh file to include:
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"solr.in.cmd file to include:
set SOLR_OPTS=%SOLR_OPTS% -Dlog4j2.formatMsgNoLookups=trueThe Log4J security page refers to setting log4j2.formatMsgNoLookups=true as a "discredited" mitigation. In reality, it depends.
We've looked at the root cause and audited the code paths that lead to the vulnerability, and we feel confident in this mitigation being sufficient for Solr.
See https://lists.apache.org/thread/kgh63sncrsm2bls884pg87mnt8vqztmz for discussion.
References: https://logging.apache.org/log4j/2.x/security.html
Severity: High
Versions Affected: 7.0.0 to 7.7.3 8.0.0 to 8.8.1
Description: The ReplicationHandler (normally registered at "/replication" under a Solr core) 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.
Mitigation: Any of the following are enough to prevent this vulnerability:
Solr 8.8.2 or greater.Credit: Reported by Caolinhong(Skay) from QI-ANXIN Cert (QI-ANXIN Technology Group Inc.)
References: SOLR-15217: CVE-2021-27905: SSRF vulnerability with the Replication handler
Severity: High
Versions Affected: 7.0.0 to 7.7.3 8.0.0 to 8.8.1
Description: 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.
Mitigation: Any of the following are enough to prevent this vulnerability:
Solr 8.8.2 or greater.Credit: Timothy Potter and Mike Drob, Apple Cloud Services
References: SOLR-15249: CVE-2021-29262: Misapplied Zookeeper ACLs can result in leakage of configured authentication and authorization settings
Severity: High
Versions Affected: 7.0.0 to 7.7.3 8.0.0 to 8.8.1
Description: When using ConfigurableInternodeAuthHadoopPlugin for authentication, Apache Solr versions prior to 8.8.2 would forward/proxy distributed requests using server credentials instead of original client credentials. This would result in incorrect authorization resolution on the receiving hosts.
Mitigation: Any of the following are enough to prevent this vulnerability:
Solr 8.8.2 or greater.Credit: Geza Nagy
References: SOLR-15233: CVE-2021-29943: Apache Solr Unprivileged users may be able to perform unauthorized read/write to collections
Severity: High
Versions Affected: 6.6.0 to 6.6.6 7.0.0 to 7.7.3 8.0.0 to 8.6.2
Description: Solr prevents some features considered dangerous (which could be used for remote code execution) to be configured in a ConfigSet that's uploaded via API without authentication/authorization. The checks in place to prevent such features can be circumvented by using a combination of UPLOAD/CREATE actions.
Mitigation: Any of the following are enough to prevent this vulnerability:
configset.upload.enabled to false (see docs)Solr 8.6.3 or greater.Credit: Tomás Fernández Löbbe, András Salamon
References: SOLR-14925: CVE-2020-13957: The checks added to unauthenticated configset uploads can be circumvented