CVE-2026-34099: Kritisk SQL-sårbarhed i Guardian
Kritisk SQL-indsprøjtning i Guardian language-system giver angribere uden login adgang til hele databasen via job_info.php.
Hvad er det?
CVE-2026-34099 er en sårbarhed i jobsystemet Guardian language-system, hvor filen job_info.php tager id-parameteren fra webadressen og sætter den direkte ind i en databasekommando uden at rense den først. Det kaldes SQL-indsprøjtning: en angriber kan skrive sin egen databasekommando ind i stedet for et almindeligt id-nummer og dermed få systemet til at udføre kommandoer, det ikke var tiltænkt. Fejlen kræver ingen brugernavn eller adgangskode, og angriberen kan bruge fejlmeddelelser fra systemet til gradvist at trække oplysninger ud af databasen, herunder version, brugernavne og indhold af tabeller.
Hvem rammer det?
Sårbarheden rammer virksomheder og organisationer, der bruger Guardian language-system, særligt jobportaler og karrieresider med et jobmodul, der viser jobopslag via job_info.php. Der er ikke oplyst konkrete versionsnumre, så vi må gå ud fra, at alle installationer med den nævnte kode er berørt, indtil leverandøren siger andet.
Hvad kan ske?
En angriber kan læse hele databasen, herunder ansøgeres personoplysninger, cv-data, brugerkonti og adgangskodehash. I værste fald kan oplysningerne bruges til identitetstyveri, videresalg eller afpresning. For en dansk virksomhed betyder det en potentiel brist på persondata, der skal vurderes efter databeskyttelsesreglerne, og et tab af tillid hos jobansøgere og kunder.
Hvor alvorligt er det?
CVSS-score er 9,8 ud af 10, hvilket er kritisk. Angrebet kan udføres over internettet, kræver ikke login, kræver ingen handling fra en bruger, og kan skade fortrolighed, integritet og tilgængelighed af data i høj grad. Der er ikke rapporteret aktiv udnyttelse, men den offentliggjorte beskrivelse indeholder den præcise kode og linje, hvor fejlen findes, hvilket gør det trivielt for en angriber at bygge et angreb.
Hvad gør jeg nu?
Vi anbefaler følgende skridt i denne rækkefølge:
- Ret koden i job_info.php, så id-parameteren renses eller sendes som en forberedt databaseforespørgsel (prepared statement), eller opdatér til en version fra leverandøren, hvis den findes.
- Kan I ikke rette koden med det samme, så bloker eller begræns adgang til job_info.php via firewall eller webserverregler, indtil rettelsen er på plads.
- Gennemgå webserverens logfiler for usædvanlige forespørgsler til id-parameteren, herunder tegn som anførselstegn, UNION og SELECT.
- Skift adgangskoder og API-nøgler, der er gemt i den samme database, hvis I finder tegn på uautoriseret adgang.
- Vurder, om der er sket en brist på persondata, og om det skal anmeldes efter databeskyttelsesreglerne.
- Kontakt en sikkerhedsrådgiver, hvis I ikke selv har kompetencerne til at rette koden eller undersøge omfanget af et muligt angreb.
Luk hullet inden for 24 timer
Vi anbefaler, at I retter eller blokerer den sårbare side i dag, da fejlen kræver hverken login eller brugerhandling og derfor kan udnyttes automatisk af scanningsværktøjer. Det er ikke i orden at vente til en planlagt vedligeholdelsesrunde, når data om jobansøgere står på spil. Er job_info.php ikke i brug eller kan lukkes helt, er det den hurtigste og sikreste løsning, mens en permanent kodeændring udarbejdes.
Tidslinje
Konkrete eksempler
Jobportal hos en dansk produktionsvirksomhed
En dansk virksomhed bruger Guardian language-system til sin karriereside, hvor ansøgere kan se ledige stillinger via job_info.php. En angriber ændrer id-parameteren i webadressen og bruger fejlmeddelelser fra siden til trin for trin at hente navne, e-mailadresser og cv-uploads fra ansøgerdatabasen. Oplysningerne bliver senere fundet til salg på et lukket forum, og virksomheden skal efterfølgende vurdere, om bristen skal anmeldes.
Ofte stillede spørgsmål
Hvordan tjekker vi, om vi bruger den sårbare kode?
Søg i jeres webapplikations kildekode efter filen job_info.php og se, om id-parameteren fra webadressen indsættes direkte i en SQL-forespørgsel uden rensning. Findes filen og linjen som beskrevet, er I berørt.
Kan vi vente til weekenden med at rette det?
Nej. Fejlen kræver ingen login og ingen brugerhandling, og angrebet kan automatiseres. Vi anbefaler at lukke hullet eller blokere siden samme dag, den bliver opdaget.
Er vi allerede blevet angrebet?
Det kan I kun vide ved at gennemgå webserverens logfiler for forespørgsler til job_info.php med usædvanlige tegn i id-parameteren, som anførselstegn eller SQL-ord som UNION og SELECT.
Skal vi anmelde det til Datatilsynet?
Hvis I finder tegn på, at persondata er blevet udtrukket eller er tilgængelige for uautoriserede, skal I vurdere anmeldepligten efter databeskyttelsesreglerne. Er der ingen tegn på misbrug, men sårbarheden var reel, bør I stadig dokumentere jeres vurdering.
Er en firewall nok til at løse problemet?
En firewall eller webapplikationsfirewall kan begrænse risikoen midlertidigt, men den fjerner ikke selve fejlen i koden. Den egentlige løsning er at rette forespørgslen i job_info.php eller opdatere til en rettet version.
Påvirker det andre dele af vores system end job_info.php?
Beskrivelsen omfatter kun job_info.php, men samme mønster kan findes i andre filer i Guardian language-system. Vi anbefaler at gennemgå alle filer, der tager parametre fra webadressen og sætter dem direkte ind i databasekommandoer.
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)
Guardian language-system passes the id GET parameter directly into an unsanitized SQL query in job_info.php (line 16): SELECT * FROM jobs where id = ‘”.$_GET[‘id’].”‘. No authentication is required. An unauthenticated attacker can perform error-based SQL injection to extract the database version, current user, schema names, and table contents.
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.