I think these names get written to a core.properties file or a directory gets created with the offending name (unless you are using solrcloud), right? Check for evidence under the solr home.
The most straightforward defense here is to do IP-based restriction on the jetty-level to only allow admin calls from localhost + (maybe) other solr servers. Different versions of solr use different versions of jetty (5.x is still war-file/tomcat era sometimes as well) so find the correct versions and secure from there. On Wed, Mar 9, 2022 at 9:40 AM Isabella Trevisan <[email protected]> wrote: > > Hi , > I have the same error but with the restart of solr it does not disappear. > My solr version is 5.2.1. > what can i do to fix the problem? > > Thank you > Regards > Isabella > > Il giorno mer 9 mar 2022 alle ore 00:20 Shawn Heisey <[email protected]> > ha scritto: > > > On 3/8/22 14:09, mtn search wrote: > > > Our company recently started running vulnerability tests against our > > Solr 6 > > > servers by sending api calls to create cores with the core names being > > > a nefarious string. This string is actually an invalid core name and so > > > the core is not actually created (which is good). However, it adds the > > > core init error to the SolrCore Initialization Failures list which is at > > > the top of every Solr Admin UI page. Overtime this list gets large... > > > > > > Restarting the Solr instance will clear these init errors from the list. > > > However, I am wondering if there is another way to clear these errors. > > > > I do not know of a way right now. Seems like there ought to be a way to > > clear that list, even if the overall low-level container isn't > > restarted. Life and work are conspiring against me and I won't have > > time to look deeper until a lot later this evening (US Mountain > > timezone). I don't think upgrading Solr would help, but version 6 is > > quite old now. You should start planning and testing for a major > > upgrade to 8.x. > > > > Thanks, > > Shawn > > > >
