CVE-2026-22674: XSS-sårbarhed i Hashgraph Guardian
Hashgraph Guardian indeholder en sårbarhed der lader en administrator injicere skadelig kode, som rammer alle brugere ved hvert sidebesøg.
Hvad er det?
CVE-2026-22674 er en såkaldt stored cross-site scripting-sårbarhed (XSS) i Hashgraph Guardian op til og med version 3.5.0. XSS betyder, at en angriber kan gemme ondsindet JavaScript-kode direkte i systemet, så den automatisk køres i browseren hos alle brugere, der besøger siden.
Konkret kan en bruger med rollen STANDARD_REGISTRY sende et manipuleret firmanavn via systemets branding-indstillinger. Systemet gemmer værdien uden at tjekke den for skadelig kode og viser den derefter ukritisk til alle andre brugere ved hvert eneste sideindlæsning.
Hvem rammer det?
Sårbarheden rammer virksomheder og organisationer, der bruger Hashgraph Guardian version 3.5.0 eller tidligere. Det er særligt relevant, hvis:
- Du har flere brugere med forskelligt adgangsniveau i systemet.
- Du har uddelegeret administrationsrettigheder til brugere med rollen STANDARD_REGISTRY.
- Systemet er tilgængeligt via internettet.
Alle brugere — uanset rolle — der logger ind i systemet, er potentielle ofre, når sårbarheden udnyttes.
Hvad kan ske?
Hvis en angriber udnytter sårbarheden, kan den skadelige kode, der kører i brugernes browsere, blandt andet:
- Stjæle login-sessioner (cookies), så angriberen kan overtage andre brugeres konti.
- Omdirigere brugere til falske login-sider for at stjæle adgangskoder (phishing).
- Læse og sende følsomme data videre fra brugerens skærm til en ekstern modtager.
- Udføre handlinger i systemet på vegne af den loggede bruger uden deres viden.
Eftersom koden gemmes i systemet og køres ved hvert sidebesøg, kan et enkelt misbrug ramme samtlige brugere løbende, indtil problemet er løst.
Hvor alvorligt er det?
Sårbarheden er vurderet til CVSS 4.8 ud af 10 — Moderat. Det er ikke det højeste niveau, men det er ikke uvæsentligt. Vurderingen er moderat, fordi angriberen skal:
- Være en autentificeret bruger, dvs. allerede have et gyldigt login med rollen STANDARD_REGISTRY.
- Kræve, at andre brugere aktivt besøger siden (hvilket de gør ved normal daglig brug).
Omvendt er det alvorligt, at angrebet er vedvarende og rammer alle brugere automatisk, og at det ikke kræver teknisk kompleksitet at udføre. Hvis en betroet bruger med STANDARD_REGISTRY-rollen er kompromitteret eller handler ondsindet, kan konsekvenserne hurtigt eskalere.
Hvad gør jeg nu?
Følg disse trin for at beskytte din virksomhed hurtigst muligt:
- Opdatér Hashgraph Guardian til en version der indeholder commit
ba8c566eller nyere. Det er den officielle rettelse fra udviklerne. - Gennemgå hvem der har STANDARD_REGISTRY-rollen i dit system. Fjern adgangen for brugere der ikke aktivt har brug for den.
- Tjek branding-indstillingerne i systemet nu og sørg for, at firmanavnet og andre branding-felter ikke indeholder uventede tegn eller scripts (fx
<script>-tags). - Informér dine brugere om at de skal melde det til dig, hvis de oplever noget usædvanligt i systemet — fx uventede omdirigeringer eller pop-up-vinduer.
- Overvåg login-aktivitet for ukendte eller mistænkelige sessioner, særligt for brugere med forhøjede rettigheder.
Opdatér inden for 7 dage
Vores klare anbefaling er, at du opdaterer Hashgraph Guardian hurtigst muligt — helst inden for den næste uge. Rettelsen er tilgængelig og begrænser angrebet direkte ved kilden. Sørg samtidig for at gennemgå hvem der har administratorrettigheder i systemet og skær ned til dem, der reelt har brug for dem — det er god praksis uanset denne sårbarhed. Har du brug for hjælp til opdateringen eller en gennemgang af dine adgangsrettigheder, er du velkommen til at kontakte os.
Tidslinje
Konkrete eksempler
Ondsindet medarbejder overtager kollegers sessioner
En medarbejder med STANDARD_REGISTRY-adgang er sur over at være blevet overset til en forfremmelse. Via branding-API’et ændrer vedkommende firmanavnet til en værdi der indeholder et skjult JavaScript-script. Næste gang en kollega — eller direktøren — logger ind, køres scriptet automatisk i browseren og sender deres session-cookie til medarbejderens server. Medarbejderen kan nu logge ind som dem og se eller ændre data i systemet.
Kompromitteret konto bruges til at sprede phishing internt
En angriber udefra har fået fat i loginoplysningerne til en STANDARD_REGISTRY-bruger via en phishing-mail. Angriberen injicerer et script der viser en falsk login-dialogboks til alle brugere. Brugerne tror de skal logge ind igen og indtaster deres adgangskode — som sendes direkte til angriberen. På den måde høster angriberen adgangskoder fra hele organisationen uden at nogen opdager det.
Automatisk dataindsamling fra alle brugere
En angriber gemmer et script i branding-konfigurationen der stille og roligt læser indholdet på hver side, brugerne besøger, og sender det til en ekstern adresse. Over dage og uger akkumuleres følsomme forretningsdata — fx transaktioner, kontaktoplysninger eller interne dokumenter — uden at nogen opdager det, da der ikke vises noget synligt for brugerne.
Ofte stillede spørgsmål
Skal vi være bekymrede, hvis vi kun har få brugere med STANDARD_REGISTRY-rollen?
Ja, selvom risikoen er mindre med få privilegerede brugere, er den ikke elimineret. En enkelt kompromitteret eller ondsindet STANDARD_REGISTRY-bruger er nok til at ramme alle andre brugere i systemet. Det anbefales stadig at opdatere og begrænse rollen til dem der reelt har behov.
Kan vi se, om vi allerede er blevet angrebet?
Det kan være svært at opdage med det blotte øje. Tjek branding-indstillingerne i systemet for mistænkeligt indhold — særligt firmanavnet. Kig også i systemets logs for usædvanlig aktivitet fra brugere med STANDARD_REGISTRY-rollen. Har du mistanke om et angreb, bør du kontakte en IT-sikkerhedsekspert til en grundigere gennemgang.
Hvad betyder det, at angriberen skal have et login i forvejen?
Det betyder, at en tilfældig person på internettet ikke kan udnytte sårbarheden direkte. Angriberen skal have et gyldigt brugernavn og adgangskode til systemet med den rigtige rolle. Det kan fx være en misfornøjet medarbejder, en tidligere ansat der ikke er blevet slettet, eller en udefrakommende der har fået fat i loginoplysninger via phishing eller datalæk.
Hvad er stored XSS, og hvorfor er det værre end andre former for XSS?
Stored XSS (lagret cross-site scripting) betyder, at den skadelige kode gemmes permanent i systemet — i modsætning til reflected XSS, hvor koden kun køres én gang via et manipuleret link. Med stored XSS rammer koden automatisk alle brugere, der besøger den inficerede side, igen og igen — uden at angriberen behøver gøre noget mere. Det gør det potentielt meget mere skadeligt.
Virker det at blokere adgang til systemet midlertidigt, mens vi venter på at opdatere?
Hvis det er praktisk muligt, kan det være en midlertidig løsning at begrænse adgangen til systemet til kun kendte og betroede netværk — fx via VPN eller IP-begrænsning. Det reducerer risikoen, men det er ikke en permanent løsning. Opdatering til den rettede version er den eneste sikre løsning.
Ramte produkter
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Hashgraph Guardian through 3.5.0, fixed in commit ba8c566, contains a stored cross-site scripting vulnerability that allows authenticated users with the STANDARD_REGISTRY role to inject malicious scripts by submitting a crafted companyName value via the branding configuration API endpoint. Attackers can exploit the unsanitized innerHTML assignment in the branding service to execute arbitrary JavaScript in the browser of every authenticated user on every page load.
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.