CVE-2026-44825: Skjulte standardkonti i Apache Solr
Apache Solr opsætter skjulte standardbrugere med offentligt kendte koder, der giver fuld adminadgang. Fjern dem eller skift kode nu.
Hvad er det?
CVE-2026-44825 er en sårbarhed i Apache Solr, en søge- og indekseringsserver, der ofte bruges til fritekstsøgning i store datamængder. Når opsætningsværktøjet bin/solr auth enable bruges til at aktivere Basic Authentication, en simpel login-metode med brugernavn og kode, opretter Solr automatisk fire skjulte skabelonkonti: superadmin, admin, search og index. Adgangskoderne til disse konti er hardcodede, altså fastindkodet i programmet, og dermed offentligt kendte i stedet for genereret unikt til hver installation. En angriber, der kender disse standardkoder, kan logge ind som administrator og få fuld kontrol over Solr-klyngen uden at have gyldige loginoplysninger i forvejen.
Hvem rammer det?
Sårbarheden rammer Apache Solr version 9.4.0 til 9.10.1 samt 10.0.0. Kun installationer, hvor man har brugt bin/solr auth enable til at oprette Basic Authentication, er berørte. Klynger, hvor authentication er sat op på anden måde, eller hvor skabelonkontiene efterfølgende har fået skiftet til stærke adgangskoder, er ikke ramt. Solr bruges ofte som søgemotor bag e-handel, intranet og fagsystemer, ofte via tredjepartsplatforme, og danske virksomheder kender derfor ikke altid selv, at de kører Solr under motorhjelmen.
Hvad kan ske?
Får en angriber adminadgang, kan vedkommende læse, ændre og slette alt indekseret data, herunder kundedata, dokumenter og søgeindeks. Solrs administrationsgrænseflade tillader også konfigurationsændringer, som i visse opsætninger kan bruges til at få adgang til den underliggende server. I praksis betyder det risiko for datatab, driftsstop på søgefunktioner og i værste fald et bredere indbrud i virksomhedens netværk.
Hvor alvorligt er det?
CVSS-score er 8,1 af 10, alvorlig. Angrebet kræver ikke login og ingen brugerhandling, og det kan udføres over netværket. Angrebskompleksiteten er sat til høj, fordi angriberen skal vide, at klyngen er sat op med bin/solr auth enable og stadig bruger skabelonkontiene med standardkoder. Er den forudsætning opfyldt, er selve angrebet enkelt at udføre. Der er ikke oplyst aktiv udnyttelse på offentliggørelsesdatoen, men koderne er offentligt kendte, hvilket gør angreb hurtige at udføre, når et sårbart system findes.
Hvad gør jeg nu?
Følgende skridt lukker hullet med det samme, uden at I skal vente på en opdatering.
- Åbn security.json og fjern skabelonkontiene superadmin, admin, search og index, eller giv dem hver en ny, stærk og unik adgangskode.
- Undersøg om jeres Solr-administrationsgrænseflade er tilgængelig fra internettet, og begræns adgangen til interne netværk eller VPN.
- Gennemgå adgangslogs for admin-login fra ukendte IP-adresser eller på usædvanlige tidspunkter.
- Planlæg opgradering til Solr 9.11.0 eller 10.1.0, når disse versioner udgives, da de retter fejlen permanent.
- Er I i tvivl om, hvordan security.json er sat op, eller om jeres Solr er eksponeret, bør I hente hjælp udefra til at gennemgå konfigurationen.
Skift standardkoder inden for 24 timer
Vi anbefaler, at I straks tjekker security.json for skabelonkontiene superadmin, admin, search og index, og fjerner dem eller giver dem stærke unikke koder. Det er den handling, der lukker hullet, og den kan I gøre i dag uden at vente på en opdatering. Det er kun i orden at vente, hvis I med sikkerhed kan dokumentere, at jeres klynge ikke er sat op med bin/solr auth enable, eller at kontiene allerede har fået skiftet adgangskode.
Tidslinje
Konkrete eksempler
Søgefunktion på webshop bliver indgang for angriber
En dansk webshop bruger Apache Solr til produktsøgning og har i sin tid sat login op med bin/solr auth enable uden at skifte standardkoderne. En angriber finder Solr-administrationssiden tilgængelig fra internettet, logger ind med den offentligt kendte kode til admin-kontoen og får adgang til hele søgeindekset, herunder kundedata knyttet til ordrehistorik. Webshoppen opdager først problemet, da uventede ændringer i søgeresultaterne bliver bemærket af kunder.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er kun ramt, hvis I kører Apache Solr 9.4.0 til 9.10.1 eller 10.0.0, og har brugt bin/solr auth enable til at sætte Basic Authentication op. Har I sat login op på anden måde, eller har I allerede skiftet skabelonkontiene, er I ikke berørte.
Hvordan tjekker vi, om vi er ramte?
Åbn filen security.json i jeres Solr-opsætning og se, om brugerne superadmin, admin, search eller index findes med standardkoder. Findes de, og har de ikke fået skiftet kode efter installation, er I sårbare.
Kan vi vente til weekenden med at rette det?
Selve rettelsen, at fjerne eller ændre kontiene, tager få minutter og bør gøres nu. Det kræver ingen nedetid eller planlagt vindue, så der er ingen praktisk grund til at vente.
Skal vi opdatere Solr nu?
Nej, versionerne 9.11.0 og 10.1.0, som retter fejlen permanent, var ikke udgivet på offentliggørelsesdatoen. Indtil da er workaround med at fjerne eller skifte kontiene den korrekte løsning.
Skal vi anmelde dette til Datatilsynet?
Kun hvis I kan konstatere, at en uautoriseret person faktisk har fået adgang til persondata via de skjulte konti. Har I lukket hullet uden tegn på misbrug, er der ingen anmeldelsespligt.
Hvad hvis vi ikke selv har sat adgangskoderne?
Har en leverandør eller integrator sat jeres Solr op, bør I kontakte dem og bede om bekræftelse på, at skabelonkontiene er fjernet eller har fået unikke koder.
Ramte produkter
Apache: Solr
≥ 9.4.0, ≤ 9.10.1
Apache: Solr
10.0.0
CVSS-detaljer
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
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
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.