Overview 2 matches · 0 protected · 0 exploited · 0 CISA KEV · 1 public PoC
Protected by Waratek
0
0.0%
Rule in development
1
50.0%
Mitigation candidate
0
0.0%
No exploit published
1
50.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
2
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
1
50.0%
Proof of concept only
0
0.0%
Forecast only
1
50.0%
No public exploit
0
0.0%
split by
peak 1 / month
Oct 20Nov 20Dec 20Jan 21Feb 21Mar 21Apr 21
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2021-27905 | Critical | 2021-04-13 | Rule in development | Working exploit published | The ReplicationHandler (normally registered at "/replication" under a Solr core) in Apache Solr 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. This problem affects essentially all Solr versions prior to it getting fixed in 8.8.2. |
| CVE-2020-13957 | Critical | 2020-10-13 | No exploit published | Forecast only | Apache Solr versions 6.6.0 to 6.6.6, 7.0.0 to 7.7.3 and 8.0.0 to 8.6.2 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. |