Veille CVE

Recherche « Apache solr »

9 CVE

Critique 2 Élevée 3 Moyenne 4 Faible 0 Non évaluée 0 Exploitées (KEV) Tri : plus récentes « Apache solr » ✕
  1. CVE-2026-19678 8.7 Élevée

    onPhase Forms

    A server-side request forgery (SSRF) vulnerability in the unauthenticated form service in version 11.0.14 in onPhase Forms allows an unauthenticated remote attacker to access sensitive internal Apache Solr data via an attacker-controlled URL supplied to a publicly accessible form.

  2. CVE-2026-50022 5.8 Moyenne

    NCEAS metacat

    Metacat is data repository software that helps researchers preserve, share, and discover data. Prior to 3.4.2, MetacatSolrIndex.query forwards the client-controlled qt parameter through Apache SolrJ from search endpoints such as /d1/mn/v2/query/solr/ to its privileged Solr backend. An unauthenticated client can select the /admin/file handler, and SolrJ reformats the parameter into a request accepted even when handleSelect=false is configured on Solr 7.0 or later. When Solr returns the selected core configuration file, Metacat embeds the raw content in an XML processing error response, disclosing internal files such as solrconfig.xml and enabling infrastructure profiling. This issue is fixed in version 3.4.2.

  3. CVE-2026-56096 6.3 Moyenne

    TYPO3 Extension "Apache Solr for TYPO3 - Enterprise Search"

    The extension passes the user-supplied search query parameter to Apache Solr without restricting advanced Solr query syntax such as wildcards, field selectors and range queries. A remote, unauthenticated attacker can use this syntax to enumerate indexed field names and extract their stored values through boolean- and range-based blind extraction techniques, independent of any site-specific configuration.

  4. CVE-2026-56095 7.7 Élevée

    TYPO3 Extension "Apache Solr for TYPO3 - Enterprise Search"

    The extension's indexer passed every field value returned by content object rendering through PHP's unserialize() function when transferring multi-value data for the SOLR_CLASSIFICATION, SOLR_MULTIVALUE and SOLR_RELATION content object types, rather than a safe format. If user-generated content saved in the TYPO3 database can reach an indexed field, this exposes a PHP Object Injection surface.

  5. CVE-2026-56094 6.3 Moyenne

    TYPO3 Extension "Apache Solr for TYPO3 - Enterprise Search"

    The extension allows a request-provided additionalFilters parameter to register a named siteHash filter before the system's own siteHash filter is applied, and the query builder does not overwrite an already-registered named filter. In a shared Solr core serving multiple TYPO3 sites, a visitor can use this to read public documents belonging to another site. The same root cause also affects the suggest top-results path when suggest is enabled.

  6. CVE-2026-56093 6.3 Moyenne

    TYPO3 Extension "Apache Solr for TYPO3 - Enterprise Search"

    The extension's frontend detail-view document lookup does not apply the current site's siteHash filter or frontend user access filter, unlike the regular search path. A visitor who can obtain or guess a valid Solr document id can retrieve documents through this lookup without the same access restrictions enforced elsewhere.

  7. CVE-2026-56092 7.6 Élevée

    TYPO3 Extension "Apache Solr for TYPO3 - Enterprise Search"

    The extension forces empty frontend-group and subpage-inheritance restrictions onto page records during indexer sub-requests, and this forged state was persisted into the shared rootline cache, allowing anonymous visitors to bypass extendToSubpages-inherited access restrictions on cached pages.

  8. CVE-2026-48203 9.1 Critique

    Apache Software Foundation Apache Camel · Apache camel

    Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel Solr component. The camel-solr producer copies Exchange message headers whose names begin with the SolrParam. prefix into the parameters of the Solr request, and headers whose names begin with the SolrField. prefix into the fields of the indexed Solr document. The prefix constants (SolrConstants.HEADER_PARAM_PREFIX / HEADER_FIELD_PREFIX) were the plain strings SolrParam. / SolrField.. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a solr: producer, any HTTP client could therefore set SolrParam.* headers to inject arbitrary Solr request parameters - including shards or stream.url, which cause the Solr server to issue server-side requests to an attacker-chosen URL (server-side request forgery, for example to an internal service or a cloud metadata endpoint), or qt to reach administrative request handlers - and set SolrField.* headers to inject arbitrary fields into indexed documents. No credentials are required when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set Solr parameters or fields via the raw header prefixes must use CamelSolrParam. / CamelSolrField. instead of SolrParam. / SolrField.. For deployments that cannot upgrade immediately, strip the SolrParam.* and SolrField.* headers from any untrusted ingress before the solr: producer, and set the required Solr parameters and fields from a trusted source in the route.

  9. CVE-2026-44825 9.8 Critique

    Apache Software Foundation Apache Solr · Apache solr

    Hardcoded credentials in the Basic Authentication setup tool (bin/solr auth enable) in Apache Solr versions 9.4.0 through 9.10.1 and 10.0.0 allows a remote attacker to gain full administrative access to the cluster via publicly known default credentials installed silently alongside the user-specified account. As an immediate workaround without upgrading, delete the template users (superadmin, admin, search, index) from security.json or change their passwords. The future, not yet released, versions 9.11.0 and 10.1.0 will not be vulnerable, and it will be enough to upgrade to solve the issue. Not affected: * Clusters where bin/solr auth enable was not used to bootstrap BasicAuth * Clusters where template users have been assigned strong passwords after bootstrap