CVE-2026-101090: Kritisk Host header-fejl i Nezha 2.2.3
Nezha 2.2.3 lækker OAuth2-login via forfalsket Host header, konti kan kapres. Sæt dashboard_host nu, ingen opdatering findes endnu.
Hvad er det?
CVE-2026-101090 er en sårbarhed i overvågningsværktøjet Nezha version 2.2.3, hvor login med OAuth2 (en standard til at logge ind via tredjepartstjenester som Google eller GitHub) kan misbruges til at overtage brugerkonti. Fejlen opstår, fordi Nezha ved login videresender den HTTP Host-header, altså oplysningen om hvilket domæne en besøgende forbinder til, som en angriber selv kan sætte, i stedet for at bruge det korrekt konfigurerede domæne. Det sker kun, når indstillingen dashboard_host er tom, hvilket er tilfældet i mange standardopsætninger. Fejlen er en gentagelse af et hul, der tidligere er rettet i Nezha, men som er kommet tilbage i version 2.2.3.
Hvem rammer det?
Sårbarheden rammer virksomheder og kommuner, der bruger Nezha 2.2.3 som overvågningspanel til servere, og som har aktiveret login via OAuth2, for eksempel med GitHub eller Google som identitetsudbyder. Det gælder specifikt installationer, hvor feltet dashboard_host i konfigurationen står tomt, hvilket ofte er tilfældet efter en standardinstallation. Alle brugerkonti på panelet, inklusive administratorkonti, er i farezonen.
Hvad kan ske?
En angriber kan sende et link eller en anmodning med en forfalsket Host-header til jeres Nezha-installation. Hvis offeret klikker på linket og starter en OAuth2-login, sendes offerets autorisationskode til en server, angriberen kontrollerer, i stedet for til jeres eget domæne. Angriberen kan derefter fuldføre login-processen som offeret og få adgang til dennes konto, herunder eventuelle administratorrettigheder. Det giver adgang til overvågningsdata om jeres serverinfrastruktur og mulighed for at ændre konfiguration eller oprette nye brugere.
Hvor alvorligt er det?
CVSS-scoren er 9,8 ud af 10, hvilket er kritisk. Angrebet kræver ikke, at angriberen er logget ind i forvejen, og selve teknikken kan udføres over netværket uden avancerede forudsætninger. I praksis kræver et succesfuldt angreb dog, at offeret klikker på et link eller åbner en anmodning, der starter login-processen med en manipuleret Host-header, så et element af social engineering indgår, selvom CVSS-vektoren angiver, at der ikke kræves brugerinteraktion i selve udnyttelsen af endepunktet. Der er ikke rapporteret aktiv udnyttelse på offentliggørelsestidspunktet, men sårbarheden er nem at forstå og kræver ingen specialviden at udnytte.
Hvad gør jeg nu?
Følg trinene i rækkefølge, da det første punkt lukker hullet uden at kræve en opdatering.
- Sæt dashboard_host til jeres faktiske domæne i Nezha-konfigurationen, så Host-headeren ikke længere bruges som fallback ved OAuth2-login.
- Deaktiver OAuth2-login midlertidigt, hvis I ikke kan sætte dashboard_host med det samme.
- Gennemgå adgangslog for usædvanlige login- eller callback-anmodninger med afvigende Host-headere.
- Følg Nezha-projektets meddelelser for en officiel opdatering og installér den, så snart den udkommer.
- Skift adgangskoder og gennemgå brugerkonti og rettigheder på panelet, hvis I finder tegn på misbrug.
- Kontakt en sikkerhedsrådgiver, hvis I ikke selv har ressourcer til at indføre workaround eller undersøge logs.
Konfigurér workaround inden for 24 timer
Vi anbefaler, at I straks sætter dashboard_host til jeres eget domæne i Nezha-konfigurationen, da det lukker hullet uden at kræve en opdatering. Er OAuth2-login ikke kritisk for jeres drift, kan I med fordel deaktivere det, indtil en rettet version foreligger. Det er ikke forsvarligt at vente til en fast opdateringsrunde, fordi konfigurationsrettelsen er hurtig at indføre, og sårbarheden er vurderet kritisk.
Tidslinje
Konkrete eksempler
Overtagelse af administratorkonto i kommunal IT-drift
En medarbejder i en kommunes IT-afdeling modtager en mail med et link, der ser ud til at føre til det interne overvågningspanel. Linket indeholder en forfalsket Host-header, og da medarbejderen logger ind via OAuth2, sendes autorisationskoden videre til angriberens server. Angriberen fuldfører login-processen og får adgang til overvågningspanelet med samme rettigheder som medarbejderen, herunder indsigt i serverstatus og mulighed for at ændre konfiguration.
Ofte stillede spørgsmål
Hvordan ved vi, om vores Nezha-installation er sårbar?
Tjek konfigurationsfilen for feltet dashboard_host. Er det tomt, og bruger I OAuth2-login, er I sårbare.
Kan vi vente til vi har tid i næste uge?
Nej, konfigurationsrettelsen tager få minutter og bør indføres med det samme, da sårbarheden er kritisk vurderet og nem at udnytte.
Er der en officiel opdatering endnu?
Nej, der forelå ingen rettet version på offentliggørelsestidspunktet den 27. september 2026. Følg Nezha-projektets meddelelser for opdateringer.
Skal vi anmelde hændelsen, hvis vi opdager misbrug?
Ja, hvis I finder tegn på, at brugerkonti er blevet overtaget, bør I vurdere anmeldelse til Datatilsynet efter reglerne om databrud og kontakte relevante myndigheder afhængigt af hvilke data der er involveret.
Påvirker det også ældre versioner af Nezha?
Sårbarheden er en gentagelse af en tidligere rettet fejl, så tjek om jeres version har den samme regression. Version 2.2.3 er bekræftet sårbar.
Kan vi bare slukke helt for OAuth2?
Ja, det er en effektiv midlertidig løsning, hvis I ikke afhænger af OAuth2-login i den daglige drift.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Nezha 2.2.3 contains a Host header injection regression in the OAuth2 redirect endpoint. When the new optional dashboard_host setting is empty, /api/v1/oauth2/{provider} (cmd/dashboard/controller/oauth2.go) reflects the attacker-supplied HTTP Host header into the redirect_uri sent to the identity provider instead of falling back to the configured install_host. An attacker who induces a victim to begin OAuth2 login via a request that reaches Nezha with a forged Host header can cause an attacker-controlled callback URL to be used as the redirect_uri; if the OAuth2 provider accepts it, the victim’s authorization code is delivered to the attacker origin, allowing the attacker to complete the OAuth2 login/binding flow and take over the account. This regresses the fix for GHSA-9rc6-8cjv-rcvx and is configuration-dependent (dashboard_host empty). At the time of the advisory no patched version was available.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.