CVE-2026-79675: Kritisk kodeudførelse i NLTK via java()
Kritisk fejl i Python-biblioteket NLTK gør det muligt at køre skadelig kode via manipulerede Java-opstartsparametre. Opdatér til NLTK 3.10.3.
Hvad er det?
NLTK er et udbredt Python-bibliotek til sprogbehandling, som mange virksomheder bruger til at analysere tekst, bygge chatbotter eller lave dataudtræk. Biblioteket har en funktion kaldet java(), der starter Java-baserede værktøjer som Stanford Parser og Stanford NER til avanceret tekstanalyse. Fejlen sidder i den måde, java()-funktionen håndterer et parameter kaldet options, som videregives til Java-programmet. NLTK validerer ikke indholdet, så en angriber kan indsætte skadelige Java-opstartsflag som -javaagent eller -agentpath. Disse flag kan bruges til at få Java-processen til at indlæse og køre vilkårlig kode på serveren, i stedet for blot at starte tekstanalysen som tiltænkt.
Hvem rammer det?
Det rammer virksomheder og kommuner, der bruger NLTK i version før 3.10.3, og hvor koden benytter java()-funktionen til at kalde Stanford-baserede sprogværktøjer. Det gælder typisk projekter med automatisk tekstanalyse, dokumentklassifikation, chatbotter eller søgefunktioner bygget i Python. Risikoen er størst, hvor applikationen lader brugere eller eksterne systemer styre indstillinger, der ender i options-parameteret, for eksempel via en webgrænseflade til sprogbehandling.
Hvad kan ske?
Hvis en angriber kan påvirke de indstillinger, der sendes til java()-funktionen, kan de få serveren til at køre vilkårlig kode. I praksis betyder det, at angriberen kan overtage den maskine, hvor tekstanalysen kører, hente eller ændre data, og bruge den som springbræt videre ind i jeres netværk. For en dansk virksomhed med en kundevendt tjeneste, der analyserer indsendt tekst eller dokumenter, kan det føre til datalæk eller kompromittering af hele serveren.
Hvor alvorligt er det?
CVSS-score er 9,8 ud af 10, hvilket er kritisk. Angrebet kræver ingen adgangskode, ingen brugerhandling fra offeret og kan udføres over netværket. Det kræver dog, at applikationen faktisk sender brugerstyret eller udefrakommende data ind i options-parameteret til java()-funktionen. Der er ikke oplysninger om, at fejlen aktivt udnyttes, men mekanismen er enkel at forstå og let at udnytte, når den rette kode-sti findes.
Hvad gør jeg nu?
Følg disse skridt for at fjerne risikoen:
- Opgradér NLTK til version 3.10.3 eller nyere i alle systemer, hvor biblioteket bruges.
- Gennemgå jeres kodebase for brug af java()-funktionen og find, om options-parameteret modtager data fra brugere, API-kald eller eksterne filer.
- Hvis I ikke kan opgradere med det samme, så fjern eller lås options-parameteret, så det aldrig indeholder brugerstyret indhold.
- Tjek logs for uventede Java-opstartsflag eller uregelmæssige processer på servere, der kører NLTK.
- Test opdateringen i et testmiljø, før den rulles ud i produktion, hvis I har tidskritiske sprogbehandlingsopgaver.
- Kontakt en sikkerhedsrådgiver, hvis I ikke selv kan finde eller vurdere, hvor java()-funktionen bruges i jeres systemer.
Opdatér inden for en uge
Vi anbefaler, at I opgraderer NLTK til 3.10.3 eller nyere snarest, og at I samtidig kortlægger, hvor java()-funktionen bruges i jeres kode. Er options-parameteret aldrig styret af brugere eller eksterne data, er risikoen begrænset, og opdateringen kan vente til næste planlagte vedligeholdelsesvindue. Er der derimod en direkte eller indirekte vej fra brugerinput til denne funktion, bør opdateringen prioriteres inden for få dage.
Tidslinje
Konkrete eksempler
Webbaseret dokumentanalyse hos en dansk virksomhed
En dansk virksomhed driver en webtjeneste, hvor kunder kan uploade dokumenter til automatisk tekstanalyse bygget på NLTK og Stanford-værktøjer. Tjenesten lader avancerede brugere angive tilpassede analyseindstillinger, som videresendes til java()-funktionen. En angriber udnytter dette til at indsætte et skadeligt -javaagent-flag og får dermed kørt egen kode på serveren, hvorfra de kan hente kundedata eller sprede sig videre i netværket.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger den sårbare funktion?
Søg i jeres Python-kode efter kald til nltk.internals.java() eller brug af Stanford-relaterede klasser i NLTK, som Stanford Parser eller Stanford NER. Undersøg derefter, hvor options-parameteret til disse kald kommer fra.
Er vi ramt, hvis vi kun bruger NLTK til simpel tekstbehandling?
Hvis I ikke bruger de Java-baserede Stanford-værktøjer via java()-funktionen, er I ikke ramt af selve angrebsvejen, men vi anbefaler stadig at opgradere, da fremtidige funktioner kan komme til at bruge samme kode.
Kan vi vente til weekenden med at opdatere?
Ja, hvis I har verificeret, at options-parameteret aldrig fyldes med brugerstyret eller udefrakommende data. Er I i tvivl, bør I opgradere så hurtigt som muligt, da fejlen giver fuld kodekørsel uden login.
Skal vi anmelde det til nogen myndighed?
Det er kun nødvendigt, hvis I konstaterer, at sårbarheden faktisk er udnyttet og har medført et sikkerhedsbrud med persondata. Uden tegn på udnyttelse er en almindelig opdatering tilstrækkelig.
Er sårbarheden udnyttet i praksis nogen steder?
Der er ingen offentlige rapporter om aktiv udnyttelse på offentliggørelsesdatoen. Det ændrer ikke ved, at fejlen er kritisk, hvis den rette angrebsvej findes i en konkret applikation.
Rammer det også vores tredjepartsleverandører?
Ja, hvis en leverandør bruger NLTK i en løsning, I benytter, bør I spørge dem, om de har opgraderet til version 3.10.3 eller nyere.
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)
NLTK before 3.10.3 fails to validate JVM options passed through the per-call options parameter in the java() function, allowing attackers to inject dangerous JVM flags. Attackers can supply malicious options like -agentpath, -javaagent, or @argfile to Stanford wrapper classes to achieve arbitrary code execution.
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.