CVE-2026-7808: Saneringsfejl i justhtml før 1.16.0
Saneringsbiblioteket justhtml kan før version 1.16.0 omgås, så skadelig kode slipper igennem. Opdatér til 1.16.0.
Hvad er det?
justhtml er et bibliotek, som udviklere bruger til at fjerne farligt indhold fra HTML, en teknik kaldet sanering. Formålet er at forhindre cross-site scripting, hvor angribere får egen kode til at køre i andre brugeres browser. I versioner før 1.16.0 er der fundet flere måder at omgå saneringen på: genbrug af saneringsregler kan svække senere kørsler, blandede store og små bogstaver i tags som ScRiPt kan blive overset, og brugerdefinerede regler for SVG- og MathML-grafik kan tillade skadelige attributter og eksterne links igennem. Problemerne rammer primært avanceret brug af biblioteket, ikke standardopsætningen JustHTML(sanitize=True). Rettet i version 1.16.0.
Hvem rammer det?
Det rammer virksomheder, hvis udviklere har bygget hjemmesider, formularer eller CMS-løsninger med justhtml til at rense brugerinput, for eksempel kommentarfelter, dokumentupload med HTML-indhold eller redigerbare tekstblokke. Risikoen er størst, hvis I selv har skrevet tilpassede saneringsregler, arbejder med SVG- eller MathML-grafik, eller behandler HTML programmatisk frem for at bruge standardindstillingen. Bruger jeres system justhtml med standardopsætningen til almindelig parsing af HTML, er I mindre udsat.
Hvad kan ske?
En angriber kan indsætte et script eller en style-blok, der ser harmløs ud, men som overlever saneringen og bliver vist på siden. Når en anden bruger, for eksempel en administrator, åbner siden, kører koden i dennes browser. Det kan bruges til at stjæle login-cookies, overtage administratoradgang eller ændre indhold på hjemmesiden uden at det umiddelbart bliver bemærket.
Hvor alvorligt er det?
CVSS-score er 9,8 ud af 10, hvilket teoretisk betegner den højeste risikokategori: angreb kræver hverken login, adgangsrettigheder eller at brugeren aktivt gør noget. I praksis afhænger den reelle risiko af, hvordan jeres udviklere har brugt biblioteket. Rammer det jeres standardopsætning, er scoren retvisende. Bruger I derimod kun den simple sanering uden tilpassede regler, er den praktiske risiko lavere, fordi angrebsvejene primært kræver avanceret eller brugerdefineret opsætning. Der er ikke offentliggjort bevis for aktiv udnyttelse på tidspunktet for offentliggørelsen.
Hvad gør jeg nu?
Følgende trin lukker hullet og reducerer risikoen, mens I undersøger jeres egen brug af biblioteket.
- Opdatér justhtml til version 1.16.0 eller nyere i alle systemer, der bruger biblioteket.
- Gennemgå jeres kode for brugerdefinerede saneringsregler, genbrugte policy-objekter eller programmatisk DOM-input, da disse mønstre er mest udsatte.
- Undersøg, om jeres løsning håndterer SVG eller MathML, og tjek om disse dele er blevet opdateret korrekt.
- Test at eksisterende input, der tidligere blev fjernet af saneringen, stadig bliver fjernet efter opdateringen.
- Gennemgå logs for uventet HTML-indhold i felter, der modtager brugerinput, hvis I ikke allerede overvåger dette.
- Kontakt en sikkerhedsrådgiver, hvis I ikke selv kan afgøre, om jeres opsætning af justhtml er berørt af den avancerede brug, sårbarheden beskriver.
Opdatér ved næste planlagte udviklingscyklus
Vi anbefaler, at I opdaterer justhtml til version 1.16.0, hvis biblioteket bruges i jeres systemer, uanset om I bruger standardopsætningen eller avanceret konfiguration. Har I ikke tilpassede saneringsregler eller SVG/MathML-understøttelse, kan opdateringen indgå i næste planlagte release i stedet for at kræve en akut ændring. Er I i tvivl om, hvordan jeres udviklere har konfigureret biblioteket, bør I få det afklaret, før I vurderer, at risikoen er lav.
Tidslinje
Konkrete eksempler
Kommentarfunktion på virksomhedens hjemmeside
En dansk virksomhed bruger justhtml til at rense HTML i kommentarer på deres hjemmeside og har tilpasset saneringsreglerne for at tillade enkelte formateringstags. En besøgende indsætter et script skjult med blandede store og små bogstaver i tagget, som overlever saneringen. Når en medarbejder senere åbner siden med kommentaren i det administrative panel, kører scriptet og stjæler medarbejderens login-session.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger justhtml?
Bed jeres udviklere eller leverandør tjekke afhængighedslisten for webapplikationer, der behandler brugerindtastet HTML, for eksempel kommentarfunktioner eller CMS-moduler. justhtml vil typisk stå i en fil med afhængigheder til projektet.
Er vi ramt, hvis vi kun bruger standardopsætningen?
Risikoen er lavere ved standardopsætningen JustHTML(sanitize=True), men den er ikke udelukket. Vi anbefaler stadig at opdatere, da det er den eneste måde at være sikker på, at alle kendte omgåelser er lukket.
Kan vi vente til den næste planlagte opdatering?
Hvis I ikke bruger avancerede funktioner som tilpassede saneringsregler, SVG eller MathML, kan opdateringen normalt vente til næste planlagte vedligeholdelse. Bruger I disse funktioner, bør opdateringen prioriteres højere.
Skal vi anmelde noget til myndighederne?
Der er ingen anmeldelsespligt alene ved at have en sårbar version installeret. Konstaterer I derimod, at sårbarheden er blevet udnyttet og persondata er kompromitteret, kan I være forpligtet til at anmelde det til Datatilsynet.
Hvordan tester vi, om opdateringen virker?
Kør en test, hvor I sender kendt skadelig HTML, for eksempel med blandede store og små bogstaver i tags, gennem jeres saneringsfunktion, og bekræft at koden bliver fjernet efter opdateringen til 1.16.0.
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)
justhtml before 1.16.0 contains multiple HTML sanitization bypass issues that can allow active/dangerous content (e.g., script or style) to survive sanitization, potentially leading to cross-site scripting. The issues primarily affect advanced usage rather than the default JustHTML(…, sanitize=True) path for ordinary parsed HTML: mutating or reusing sanitization policy objects (including exported defaults) could weaken later sanitization; programmatic DOM input to sanitize()/sanitize_dom() could miss mixed-case tag names (e.g., ScRiPt, StYlE); crafted programmatic doctype names could serialize into active markup; and custom policies preserving SVG or MathML could allow animation elements, presentation attributes with external url(…) references, or DOM trees mislabeled as namespace=”html” to bypass foreign-content checks. Fixed in 1.16.0.
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.