CVE-2026-78683: Kritisk fejl i Python-biblioteket NLTK
Kritisk fejl i Python-biblioteket NLTK (CVE-2026-78683) lader ondsindede model-filer køre kode. Opdatér til NLTK 3.10.0.
Hvad er det?
NLTK er et udbredt Python-bibliotek til sprogbehandling, som bruges i chatbots, tekstanalyse og andre systemer, der forstår naturligt sprog. Sårbarheden CVE-2026-78683 sidder i funktionen TransitionParser.parse(), som indlæser gemte sprogmodeller fra fil. Funktionen bruger Pythons pickle-format til at gemme og genskabe data, men gør det uden de sikkerhedstjek, biblioteket faktisk har indbygget i en separat, sikker udgave. CWE-502 er navnet på denne fejltype, kaldet usikker deserialisering: et program genskaber objekter fra en fil uden at kontrollere, om filen faktisk kun indeholder data eller også indeholder kode. En model-fil kan derfor bygges, så den udfører vilkårlig Python-kode, i stedet for blot at levere en sprogmodel, når den indlæses af et sårbart program.
Hvem rammer det?
Fejlen rammer alle systemer, der bruger NLTK i version 3.9.4 eller ældre, og som benytter TransitionParser.parse() til at indlæse sprogmodeller fra fil. Det er typisk virksomheder med hjemmebyggede chatbots, tekstanalyseværktøjer, dataklassificering eller forskningsprojekter, hvor modeller downloades eller deles mellem systemer og medarbejdere. Er modellen hentet fra en ekstern kilde, en samarbejdspartner eller et offentligt tilgængeligt lager, er risikoen størst.
Hvad kan ske?
En angriber kan bygge en model-fil, der ser ud som en almindelig NLTK-sprogmodel, men som indeholder skjult kode. Indlæser en medarbejder eller et system filen, for eksempel ved at hente en model fra internettet eller åbne en fil tilsendt via mail, kører koden med de samme rettigheder som det program, der indlæser filen. I praksis kan det give angriberen fuld adgang til serveren eller den arbejdsstation, hvor programmet køres, herunder mulighed for at stjæle data, installere yderligere skadelig kode eller bevæge sig videre i netværket.
Hvor alvorligt er det?
CVSS-scoren er 9,6 ud af 10, hvilket er kritisk. Angrebet kræver ikke login eller særlige rettigheder, men kræver brugerhandling: en person eller et system skal aktivt indlæse den ondsindede model-fil, før koden kører. Sårbarheden kan udnyttes over netværk, og konsekvensen rammer alle tre klassiske sikkerhedsmål fuldt ud: fortrolighed, integritet og tilgængelighed. Der er ikke oplysninger om, at fejlen aktivt udnyttes i angreb på offentliggørelsestidspunktet, men den tekniske beskrivelse er detaljeret nok til, at et angreb kan bygges uden stort besvær.
Hvad gør jeg nu?
Sårbarheden lukkes ved at opdatere biblioteket. Følg punkterne herunder.
- Opdatér NLTK til version 3.10.0 eller nyere i alle systemer og udviklingsmiljøer, hvor biblioteket bruges.
- Find alle steder i egne applikationer, hvor TransitionParser.parse() eller anden pickle-baseret indlæsning af modeller bruges, og bekræft, at de peger på den opdaterede pakke.
- Undlad at indlæse model-filer fra kilder, I ikke selv kontrollerer eller har verificeret, indtil opdateringen er gennemført.
- Gennemgå logfiler for tegn på, at ukendte eller ændrede model-filer er blevet indlæst før opdateringen.
- Overvej at bruge NLTKs sikre indlæsningsfunktion, RestrictedUnpickler, i egen kode, hvor det er muligt, som en ekstra beskyttelse.
- Er I i tvivl om, hvilke systemer der bruger NLTK, eller har I ikke ressourcer til at gennemgå koden selv, bør I hente hjælp udefra til at kortlægge og opdatere systemerne.
Opdatér før næste model-indlæsning
Vi anbefaler, at I opdaterer NLTK til version 3.10.0 så hurtigt som muligt i alle systemer, der bruger biblioteket til at indlæse modeller. Det er kun forsvarligt at vente, hvis I med sikkerhed kan dokumentere, at ingen af jeres systemer indlæser model-filer fra eksterne eller ubekræftede kilder. Er I i tvivl om, hvor NLTK bruges i jeres kodebase, bør I få lavet en kortlægning, før I beslutter jer for at vente.
Tidslinje
Konkrete eksempler
Chatbot indlæser model fra ekstern kilde
En dansk virksomhed bruger NLTK til at drive en kundeservice-chatbot og henter jævnligt opdaterede sprogmodeller fra et delt filarkiv hos en underleverandør. En angriber, der har fået adgang til arkivet eller udgiver sig for at være underleverandøren, lægger en ondsindet model-fil ind i arkivet. Når virksomhedens system automatisk henter og indlæser den nye model, køres angriberens kode på virksomhedens server, hvilket giver adgang til interne systemer og data.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er ramt, hvis I bruger Python-biblioteket NLTK i version 3.9.4 eller ældre, og jeres system indlæser sprogmodeller fra fil via funktioner som TransitionParser.parse(). Tjek jeres kravfil eller pakkeliste for NLTK-versionen.
Hvordan tjekker vi, hvilken version af NLTK vi bruger?
Kør kommandoen ‘pip show nltk’ i det Python-miljø, hvor biblioteket er installeret, eller kig i jeres afhængighedsfil, for eksempel requirements.txt. Er versionen 3.9.4 eller lavere, er I sårbare.
Kan vi vente til weekenden med at opdatere?
Ja, hvis ingen af jeres systemer i mellemtiden indlæser model-filer fra eksterne eller ubekræftede kilder. Bruger I model-filer fra kilder uden for jeres kontrol, bør opdateringen prioriteres før weekenden.
Skal vi anmelde noget til myndighederne?
Der er ikke krav om anmeldelse, alene fordi biblioteket er sårbart. Har I konstateret, at en ondsindet model-fil rent faktisk er blevet indlæst i jeres systemer, kan det udløse anmeldelsespligt efter databeskyttelsesreglerne, hvis persondata er kompromitteret.
Påvirker opdateringen vores eksisterende modeller og kode?
Opdateringen til 3.10.0 retter selve indlæsningsmekanismen og bør ikke ændre, hvordan jeres egne, tillidsværdige modeller fungerer. Vi anbefaler dog altid at teste opdateringen i et testmiljø, før den rulles ud i produktion.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
NLTK before 3.10.0 (affected versions <=3.9.4) contains an unsafe pickle deserialization vulnerability in the TransitionParser.parse() method (nltk/parse/transitionparser.py). The method calls pickle_load() with the default restricted=False, routing deserialization through WarningUnpickler, which does not override find_class() and therefore permits arbitrary class resolution. When an application loads an attacker-crafted model file, embedded pickle gadget chains execute arbitrary Python code with the privileges of the user running the application. NLTK provides a RestrictedUnpickler for safe deserialization, but it is not used by production code paths. Fixed in 3.10.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.