CVE-2026-80428: Kritisk ILIAS-sårbarhed – opdater nu
Kritisk fejl i ILIAS e-læringsplatform lader hackere overtage serveren uden at logge ind – opdater straks til version 9.22, 10.10 eller 11.3.
Hvad er det?
ILIAS er en open source e-læringsplatform, som mange uddannelsesinstitutioner og virksomheder bruger til kurser og undervisning. En kritisk sikkerhedsfejl gør det muligt for en angriber – uden at have et brugernavn eller kodeord – at sende skadelig kode til serveren og få den udført.
Fejlen opstår fordi ILIAS behandler gemt sessionsdata (midlertidige brugeroplysninger) på en usikker måde. En bestemt del af systemet – Shibboleth-logout-funktionen – åbner sessionsdata fra alle aktive brugere og behandler dem uden at tjekke, om afsenderen er en rigtig bruger. En angriber kan plante skadelige data i systemet via et andet ubeskyttet indgangspunkt (LTI-login) og dermed få sin kode udført på serveren.
Hvem rammer det?
Sårbarheden rammer alle organisationer, der driver en ILIAS-installation på en server – typisk:
- Uddannelsesinstitutioner (skoler, universiteter, erhvervsskoler)
- Virksomheder der bruger ILIAS til intern medarbejderuddannelse
- Kommuner og offentlige institutioner med e-læringsbehov
Hvis I bruger en version ældre end 9.22, 10.10 eller 11.3, er I potentielt sårbare. Bruger I en cloud-hostede version, bør I tjekke med jeres leverandør om de allerede har opdateret.
Hvad kan ske?
En angriber kan udnytte fejlen til at overtage den server, som ILIAS kører på. I praksis betyder det:
- Fuldstændig kontrol over serveren – angriberen kan installere programmer, slette data eller bruge serveren til videre angreb
- Datatyveri – adgang til alle brugeroplysninger, kursusdata og eventuelle dokumenter gemt i systemet
- Manipulation af indhold – angriberen kan ændre kursusmateriale eller oprette falske brugere
- Springbræt til resten af netværket – hvis serveren er forbundet til andre systemer internt, kan angriberen bevæge sig videre derfra
Det kritiske er, at alt dette kan ske uden at angriberen har adgang til et gyldigt login.
Hvor alvorligt er det?
Fejlen er bedømt til CVSS-score 9.8 ud af 10 – Kritisk. Det er den højeste risikoklasse. Karakteren afspejler at:
- Angrebet kan udføres over internettet fra hele verden
- Det kræver ingen brugernavn, kodeord eller teknisk forhåndsviden om målet
- Det kræver ingen handling fra en bruger på jeres side
- Angriberen opnår fuld kontrol (læsning, ændring og sletning af data samt serverdrift)
CWE-502 (Deserialisering af upålidelige data) er en velkendt og alvorlig fejltype, som angribere har erfaring med at udnytte.
Hvad gør jeg nu?
Handler du hurtigt, reducerer du risikoen markant. Gør følgende i prioriteret rækkefølge:
- Find ud af hvilken version I kører: Log ind som administrator i ILIAS og tjek versionnummeret under Administration → Generelle indstillinger.
- Opdater til en sikker version: Opdater til ILIAS 9.22, 10.10 eller 11.3 (eller nyere). Disse versioner fjerner den sårbare funktionalitet. Download fra ilias.de.
- Kan I ikke opdatere straks – begræns adgangen: Bloker midlertidigt ekstern adgang til stien
components/ILIAS/AuthShibboleth/resources/shib_logout.phpog LTI-indgangspunktet via jeres firewall eller webserver-konfiguration. - Tjek for tegn på kompromittering: Gennemgå server-logs for usædvanlig aktivitet, ukendte filer under web-roden eller mistænkelige brugeroprettelser.
- Orienter jeres hosting-udbyder: Hvis ILIAS drives af en ekstern leverandør, kontakt dem og bed om bekræftelse på, at de har opdateret.
Opdater inden for 24-48 timer
Denne sårbarhed er ekstremt alvorlig, fordi den ikke kræver noget login og giver fuld serveradgang. Opdater ILIAS til en af de patchede versioner (9.22, 10.10 eller 11.3) hurtigst muligt – helst inden for det næste døgn. Hvis I ikke kan opdatere med det samme, bør I som minimum blokere adgangen til de berørte URL-stier på serveren, og overveje at tage ILIAS offline midlertidigt, hvis systemet er eksponeret mod internettet. Kontakt os gerne, hvis I har brug for hjælp til at vurdere jeres situation eller gennemføre opdateringen sikkert.
Tidslinje
Konkrete eksempler
Angriber planter skadelig kode via LTI-login
En angriber besøger jeres ILIAS-installations LTI-indgangspunkt (et åbent login-punkt til eksterne læringsværktøjer) og sender en manipuleret anmodning med skadelige serialiserede data som parameter. ILIAS gemmer disse data i sessionsbasen uden at validere dem. Dernæst kalder angriberen Shibboleth-logout-endepunktet, som læser alle aktive sessioner inklusive den skadelige og kører koden. Angriberen har nu fuld adgang til serveren – alt dette uden ét eneste gyldigt login.
Fildropning og webshell-installation
Ved at udnytte den skadelige kodes evne til at skrive filer til en vilkårlig sti under web-roden, opretter angriberen en ‘webshell’ – en lille skjult fil der fungerer som en bagdør til serveren. Via denne fil kan angriberen efterfølgende styre serveren fra sin egen computer, kopiere alle brugeres data ud af databasen og sprede sig til andre systemer på jeres netværk.
Datatyveri og GDPR-brud
En angriber udnytter sårbarheden til at få adgang til ILIAS-databasen, der indeholder navne, e-mailadresser, kursusresultater og muligvis CPR-numre eller andre personoplysninger på alle brugere og kursusdeltagere. Oplysningerne eksporteres lydløst. Organisationen opdager bruddet først uger senere – og er nu forpligtet til at anmelde det til Datatilsynet inden for 72 timer samt informere de berørte personer.
Ofte stillede spørgsmål
Vi bruger ILIAS via en ekstern leverandør – er vi beskyttet?
Det afhænger af om leverandøren allerede har opdateret til en sikker version. Kontakt dem direkte og bed om skriftlig bekræftelse på, at de kører version 9.22, 10.10, 11.3 eller nyere. Acceptér ikke blot en mundtlig forsikring.
Kan vi se om nogen allerede har udnyttet fejlen mod os?
Kig i jeres webserver-logs (typisk access.log) efter kald til stierne
shib_logout.phpog LTI-login-endepunktet fra ukendte IP-adresser. Kig også efter nye og ukendte filer under web-roden. Hvis I er usikre, kan en cybersikkerhedskonsulent hjælpe med en hurtig gennemgang.Hvad er 'deserialisering', og hvorfor er det farligt?
Serialisering er en metode til at gemme komplekse data (f.eks. en brugersession) som en tekststreng. Deserialisering er at læse tekststrengen og genskabe dataene. Problemet opstår, når systemet genskaber data fra en kilde det ikke kan stole på – det svarer til at åbne en pakke fra en ukendt afsender og lade indholdet køre frit i huset. En angriber kan pakke skadelig kode ind i datastrukturen og få systemet til at udføre den.
Bruger vi ikke Shibboleth – er vi så stadig sårbare?
Ja, desværre. Selvom Shibboleth er et SSO-system (Single Sign-On), er den sårbare kode en del af ILIAS’ standardinstallation og er tilgængelig på alle installationer, uanset om I aktivt bruger Shibboleth-login. Det er selve endpoints tilstedeværelse – ikke brugen af det – der udgør risikoen.
Koster opdateringen noget?
ILIAS er open source og gratis at opdatere. Selve softwareopdateringen er uden licensomkostninger. Udgiften vil typisk være den tid, jeres IT-ansvarlige eller leverandør bruger på at gennemføre og teste opdateringen. Det er en investering der er værd at prioritere givet sårbarhedens alvor.
Hvad sker der hvis vi venter med at opdatere?
Jo længere I venter, jo større er risikoen. Fejlen er offentligt kendt, og angribere scanner aktivt internettet for sårbare systemer. En ubeskyttet ILIAS-installation kan kompromitteres uden varsel, og konsekvenserne – datatyveri, serverovertag, GDPR-brud – kan være langt dyrere at håndtere end en hurtig opdatering.
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)
ILIAS deserialises stored session data for an unauthenticated caller. The Shibboleth back-channel endpoint at components/ILIAS/AuthShibboleth/resources/shib_logout.php runs in a context that ilInitialisation exempts from authentication, and its logout-notification handler locates the session to terminate by reading every live row of the session table and passing each row’s stored data to a hand-written parser that calls unserialize without restricting which classes may be constructed. Any serialised object present in any session row is therefore instantiated on behalf of an anonymous request, and object destructors run when those objects are discarded. A serialised object can be placed into a session row without logging in, because the LTI authentication entry point stores request parameters into the session and is reachable on a path the same initialisation code exempts from authentication. A class bundled with the application writes a JSON-encoded structure to a file named by one of its own properties when it is destroyed, which places attacker-controlled content at an attacker-chosen path below the web root and results in code execution as the web server user. Versions 9.22, 10.10 and 11.3 remove the endpoint’s logout-notification implementation.
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.