Evidence used
- No CISA KEV confirmation is currently recorded.
- A structured source references public exploit or proof-of-concept material.
- EPSS is 83.72% for the current model date.
BlackTreeCVE IntelligenceApache Software Foundation · Apache Solr
High technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance.
Debian findings are scoped to the named distribution, release and source package. An absent finding does not mean a package is unaffected.
A published vendor fix does not prove that a matching update is enabled and installable on a particular asset. Confirm the local package candidate before scheduling remediation.
| Distribution release | Source package | Vendor state | Fixed version | Evidence |
|---|---|---|---|---|
| Debian trixietrixie · source | lucene-solr | Vendor fix publishedDebian records a fixed source-package version for this release. | 3.6.2+dfsg-23 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian bookwormbookworm · source | lucene-solr | Vendor fix publishedDebian records a fixed source-package version for this release. | 3.6.2+dfsg-23 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian forkyforky · source | lucene-solr | Vendor fix publishedDebian records a fixed source-package version for this release. | 3.6.2+dfsg-23 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian sidsid · source | lucene-solr | Vendor fix publishedDebian records a fixed source-package version for this release. | 3.6.2+dfsg-23 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
These OSV and GitHub advisory ranges apply only to the named package and ecosystem. A listed fixed version is not a universal product patch or proof that an update is installed.
| Ecosystem and package | Affected range | First fixed version | Evidence |
|---|---|---|---|
| Mavenorg.apache.solr:solr-core | ECOSYSTEM: introduced 6.0.0; fixed 8.11.3 | 8.11.3 | OSV record ↗aggregator derived · 10 Sep 2026 |
| Mavenorg.apache.solr:solr-core | ECOSYSTEM: introduced 9.0.0; fixed 9.4.1 | 9.4.1 | OSV record ↗aggregator derived · 10 Sep 2026 |
| mavenorg.apache.solr:solr-core | >= 6.0.0, < 8.11.3 | 8.11.3 | GitHub advisory ↗github reviewed aggregator · 13 Feb 2025 |
| mavenorg.apache.solr:solr-core | >= 9.0.0, < 9.4.1 | 9.4.1 | GitHub advisory ↗github reviewed aggregator · 13 Feb 2025 |
High technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance.
Fix not verifiedImproper 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.
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.
The upload path does not sufficiently restrict the type, name, location or later execution of attacker-supplied files.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
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.
The upload path does not sufficiently restrict the type, name, location or later execution of attacker-supplied files.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
CISA Vulnrichment records proof-of-concept exploitation in its SSVC data. BlackTree has not independently executed or validated exploit material.
CWE-434: Unrestricted Upload of File with Dangerous Type. The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 9 Feb 2024 · Last source change 24 Apr 2025, 15:47 UTC · CWE-434 · Unrestricted Upload of File with Dangerous Type
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.