CVE-2026-44825: Kritisk sårbarhed i Apache Solr
Apache Solr indeholder hemmelige standardadgangskoder, der giver angribere fuld administratoradgang til din søgemaskine.
Hvad er det?
Apache Solr er en populær open source-søgeplatform, som mange virksomheder bruger til at søge i store mængder data. Denne sårbarhed betyder, at når du aktiverer adgangskodebeskyttelse via det indbyggede opsætningsværktøj (bin/solr auth enable), installeres der automatisk og lydløst en række ekstra standardbrugere med kendte adgangskoder — udover den bruger, du selv opretter. Disse skjulte brugere er kendte af offentligheden, og en angriber kan bruge dem til at logge ind med fuld administratoradgang. Problemet skyldes hårdkodede legitimationsoplysninger (dvs. brugernavne og adgangskoder der er fast indlejret i programkoden).
Hvem rammer det?
Sårbarheden rammer dig, hvis:
- Du kører Apache Solr i version 9.4.0 til og med 9.10.1, eller version 10.0.0.
- Du har brugt kommandoen
bin/solr auth enabletil at slå Basic Authentication (adgangskodebeskyttelse) til. - Du efterfølgende ikke har ændret adgangskoderne på standardbrugerne (superadmin, admin, search, index) i filen
security.json.
Har du aldrig aktiveret Basic Authentication via dette værktøj, eller har du allerede ændret standardbrugernes adgangskoder til stærke, unikke adgangskoder, er du ikke berørt.
Hvad kan ske?
En angriber, der kender de offentligt kendte standardadgangskoder, kan logge ind på din Solr-installation med fuld administratoradgang — uden at have brug for nogen særlige forhåndstilladelser. Det betyder, at angriberen kan:
- Læse alle data i din søgeindeks, herunder potentielt kundeoplysninger, produktdata eller interne dokumenter.
- Ændre eller slette data i indekset og derved ødelægge din søgefunktion eller forfalske resultater.
- Gøre systemet utilgængeligt (nedlægge servicen) for dine brugere eller kunder.
- Potentielt anvende Solr som et springbræt til andre systemer på dit netværk.
Hvor alvorligt er det?
Sårbarheden er vurderet til 8.1 ud af 10 (Alvorlig) af den internationale CVSS-skala. Angrebet kan udføres over internettet uden forudgående adgang eller særlige rettigheder, og det kompromitterer fortrolighed, integritet og tilgængelighed fuldt ud. Den eneste faktor der begrænser scoren en smule er, at angrebet kræver en vis teknisk kompleksitet at gennemføre. De underliggende svagheder (CWE-798 og CWE-1188) dækker henholdsvis hårdkodede legitimationsoplysninger og usikre standardindstillinger — begge er velkendte angrebsmønstre som angribere aktivt søger efter.
Hvad gør jeg nu?
Du bør handle hurtigt. Her er, hvad du konkret skal gøre:
- Find ud af, om du er berørt: Tjek om du kører Solr 9.4.0–9.10.1 eller 10.0.0, og om du har brugt
bin/solr auth enabletil at opsætte adgangskodebeskyttelse. - Øjeblikkelig afhjælpning (uden opgradering): Åbn filen
security.jsoni din Solr-installation og slet eller skift adgangskoderne på standardbrugerne: superadmin, admin, search og index. Brug stærke, unikke adgangskoder. - Opgrader Solr: Så snart version 9.11.0 eller 10.1.0 udgives, opgradér din installation. Disse versioner vil ikke indeholde sårbarheden.
- Begræns netværksadgang: Hvis Solr ikke behøver at være tilgængelig fra internettet, så sørg for at begrænse adgangen via firewall til kun de systemer, der har brug for det.
- Gennemgå adgangslogge: Tjek om der har været mistænkelige login-forsøg eller adgang med standardbrugernavne på din installation.
Afhjælp inden for 48 timer
Da de kendte standardadgangskoder er offentligt tilgængelige, er risikoen for aktivt misbrug reel og umiddelbar. Vi anbefaler, at du straks sletter eller ændrer standardbrugerne i security.json — det er en hurtig handling, der effektivt lukker hullet, mens du venter på en officiel opdatering. Planlæg desuden en opgradering til version 9.11.0 eller 10.1.0 så snart de frigives. Kontakt os, hvis du har brug for hjælp til at gennemføre disse trin sikkert.
Tidslinje
Konkrete eksempler
Direkte login med standardadgangskode
En angriber scanner internettet efter Solr-installationer på standardporten 8983 og finder din virksomheds server. Ved at prøve det kendte standardbrugernavn superadmin med den hårdkodede adgangskode opnår angriberen fuld administratoradgang på få sekunder — uden at skulle knække nogen kode. Derfra kan angriberen læse alle data i søgeindekset, herunder kundeoplysninger eller interne dokumenter.
Datasletning og sabotage af søgefunktion
En konkurrent eller ondsindet aktør logger ind via standardbrugeren admin og sletter eller ødelægger dine søgeindekser. For en webshop betyder det, at kunderne ikke længere kan søge i produkter, hvilket direkte påvirker salget. Genetableringen kan tage dage, hvis der ikke er taget backup.
Solr som springbræt ind i interne systemer
Hvis din Solr-server ligger på et internt netværk og er forbundet til andre systemer — fx en database eller et filsystem — kan en angriber, der har opnået administratoradgang til Solr, bruge denne adgang til at forsøge at bevæge sig videre til andre interne systemer. Det kan i værste fald føre til et bredere databrud eller ransomware-angreb på virksomhedens øvrige infrastruktur.
Ofte stillede spørgsmål
Hvordan ved jeg, om min Solr-installation er sårbar?
Du er sårbar, hvis du opfylder tre betingelser: (1) Du bruger Solr version 9.4.0–9.10.1 eller 10.0.0, (2) du har aktiveret adgangskodebeskyttelse med kommandoen
bin/solr auth enable, og (3) du ikke efterfølgende har ændret eller slettet standardbrugerne superadmin, admin, search og index i filensecurity.json. Mangler blot ét af disse punkter, er du sandsynligvis ikke berørt.Hvad er 'hårdkodede adgangskoder', og hvorfor er det farligt?
Hårdkodede adgangskoder er brugernavne og adgangskoder, der er fast indskrevet i programmets kildekode — i stedet for at blive genereret tilfældigt eller valgt af dig. Det betyder, at de er ens for alle installationer verden over og kendes af alle, der har adgang til kildekoden. En angriber behøver blot at prøve de kendte standardværdier for at få adgang.
Er det nok at have en firewall foran Solr?
En firewall reducerer risikoen betydeligt, men er ikke tilstrækkelig som eneste foranstaltning. Hvis Solr er tilgængeligt fra internettet — eller fra et netværkssegment, som en angriber allerede har adgang til — er du stadig i fare. Du bør kombinere firewall-beskyttelse med at ændre eller slette standardbrugerne og opgradere til en ikke-sårbar version.
Hvornår kommer den officielle patch?
Apache har oplyst, at de kommende versioner 9.11.0 og 10.1.0 vil rette sårbarheden fuldstændigt. Disse versioner var ikke frigivet på tidspunktet for CVE-offentliggørelsen den 1. juni 2026. Hold øje med Apache Solrs officielle udgivelsesside, og opgrader så snart de er tilgængelige.
Kan jeg se, om nogen allerede har udnyttet sårbarheden mod mig?
Ja, delvist. Gennemgå Solrs adgangslogge og kig efter login-forsøg eller vellykkede logins med brugernavnene superadmin, admin, search eller index — især fra IP-adresser, du ikke genkender. Uventede login-aktiviteter fra disse konti bør undersøges nærmere. Kontakt en sikkerhedsekspert, hvis du finder mistænkelig aktivitet.
Hvad er Apache Solr, og hvorfor bruger virksomheder det?
Apache Solr er et open source-søgeprogram, som virksomheder bruger til at tilbyde hurtig og avanceret søgefunktionalitet i store datamængder — fx søgning på en webshop, i et dokumentarkiv eller i et intranet. Det er gratis og meget udbredt, men kræver korrekt konfiguration for at være sikkert.
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.