WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕Vendor org.apache.solr✕
Overview 1 match · 0 in Waratek scope · 0 protected · 0 CISA KEV · 0 EPSS ≥ 0.5
1match 0in Waratek scope0.0% 0protected0.0% 0CISA KEV0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0% Outside Waratek scope 1 100.0% Not applicable 0 0.0% Withdrawn CVE 0 0.0%
Critical 1 100.0% High 0 0.0% Medium 0 0.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 1 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 1 100.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 0 0.0%
split by peak 1 / month
Outside Waratek scope: 1 Critical: 1 not blocked: 1 Exploited: 1
Jun 261 Outside Waratek scope1 Critical1 not blocked1 Exploited1
Jun 26
1 match Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-44825 Critical 2026-06-01 Outside Waratek scope Exploited 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