CVE-2026-58449: Kritisk kodeinjektion i txtai
Ubeskyttet /reindex-funktion i txtai giver angribere mulighed for at køre vilkårlig kode. Opdatér txtai eller luk API’et af.
Hvad er det?
CVE-2026-58449 er en sårbarhed i txtai, et open source-bibliotek der bruges til at bygge AI-drevne søgemaskiner og indekser af tekst. Sårbarheden findes i API-funktionen /reindex, som modtager en parameter kaldet function. Denne parameter sendes videre til en intern funktion, txtai.util.Resolver, der importerer og kalder kode ud fra den sti, brugeren angiver, uden at tjekke om stien er tilladt. En angriber kan derfor angive en vilkårlig Python-funktion, for eksempel en der kører systemkommandoer, og få den kørt på serveren. Fejlen kaldes kodeinjektion (CWE-94). Den rammer, når txtai’s API kører uden adgangskontrol og med et indeks, der kan skrives til. Fejlen er rettet i commit 11b32da, som kræver en aktiv konfiguration for at slå reindex-funktionen til.
Hvem rammer det?
Det rammer virksomheder og kommuner, der har opsat txtai som en API-tjeneste, i version 9.10.0 eller tidligere, uden at have konfigureret en adgangstoken (TOKEN). Autentifikation i txtai er valgfri og slået fra som standard, så hvis API’et er tilgængeligt fra internettet eller et internt netværk uden yderligere beskyttelse, og indekset er sat op til at kunne skrives til, er systemet sårbart. Det er typisk relevant for teams, der har bygget interne søgeløsninger, chatbots eller dokumenthåndtering oven på txtai.
Hvad kan ske?
En angriber, der finder et eksponeret txtai-API uden token, kan sende et kald til /reindex og få serveren til at afvikle vilkårlige systemkommandoer. I praksis betyder det fuld kontrol over den server, hvor txtai kører, herunder mulighed for at stjæle data, installere skadelig kode eller bruge serveren som adgang videre ind i jeres netværk. For en dansk virksomhed kan det føre til tab af følsomme dokumenter, driftsstop og i værste fald spredning af ransomware til andre systemer.
Hvor alvorligt er det?
CVSS-scoren er 9,8 ud af 10, hvilket er kritisk. Angrebet kræver ingen login, ingen brugerhandling og kan udføres over netværket med lav teknisk kompleksitet. Det, der begrænser risikoen, er at sårbarheden kun kan udnyttes, hvis API’et er eksponeret, autentifikation ikke er slået til, og indekset er skrivbart. Det er ikke standardopsætningen, men mange interne værktøjer bliver sat op hurtigt uden at TOKEN aktiveres. Der er ikke oplysninger om, at sårbarheden aktivt udnyttes i angreb på offentliggørelsestidspunktet.
Hvad gør jeg nu?
Gør følgende for at lukke hullet og begrænse risikoen:
- Opdatér txtai til en version, der indeholder rettelsen fra commit 11b32da, hvor reindex-funktionen kræver en eksplicit konfiguration for at være aktiv.
- Kan I ikke opdatere med det samme, så aktivér TOKEN-baseret autentifikation på jeres txtai-API, så uautoriserede kald afvises.
- Afgræns netværksadgangen til API’et, så det kun kan tilgås fra betroede systemer, for eksempel via firewall eller netværkssegmentering.
- Gennemgå logs for kald til /reindex-endepunktet for at se, om der har været unormal eller uautoriseret aktivitet.
- Sæt indekset til skrivebeskyttet, hvis jeres løsning ikke har brug for at kunne genindeksere via API’et.
- Er I i tvivl om, hvordan txtai er konfigureret i jeres miljø, eller om I allerede er blevet ramt, bør I få en ekstern sikkerhedsrådgiver til at gennemgå opsætningen.
Opdatér inden for 48 timer
Vi anbefaler, at I straks tjekker, om jeres txtai-installation eksponerer API’et uden TOKEN, og at I opdaterer til den rettede version snarest muligt. Er API’et kun tilgængeligt internt og TOKEN allerede aktiveret, kan opdateringen planlægges som en almindelig driftsopgave uden akut hastværk. Er API’et derimod tilgængeligt fra internettet uden adgangskontrol, bør det lukkes ned eller beskyttes, indtil opdateringen er gennemført.
Tidslinje
Konkrete eksempler
Intern søgeløsning uden adgangskontrol
En dansk mellemstor virksomhed har opsat txtai som en intern søgemaskine til deres dokumentarkiv og har gjort API’et tilgængeligt for udviklingsteamet uden at aktivere TOKEN, fordi det var hurtigere at komme i gang. En medarbejders bærbare bliver kompromitteret, og angriberen finder frem til det interne API. Ved at kalde /reindex med en ondsindet function-parameter opnår angriberen kørsel af systemkommandoer på serveren og kan derfra tilgå følsomme dokumenter og bevæge sig videre i netværket.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi bruger den sårbare version af txtai?
Tjek den installerede version af txtai i jeres miljø. Er den 9.10.0 eller tidligere, og indeholder den ikke rettelsen fra commit 11b32da, er I sårbare, hvis API’et er eksponeret uden TOKEN.
Er vi ramt, hvis vi kun bruger txtai internt?
Risikoen er mindre, men ikke nul. Hvis andre medarbejdere, systemer eller et kompromitteret internt netværk kan nå API’et uden TOKEN, kan sårbarheden stadig udnyttes. Vi anbefaler at aktivere TOKEN uanset placering.
Kan vi vente til weekenden med at opdatere?
Hvis jeres API allerede kræver TOKEN, eller kun er tilgængeligt fra et lukket netværk, kan I vente til næste planlagte vedligeholdelsesvindue. Er API’et tilgængeligt fra internettet uden TOKEN, bør det lukkes eller beskyttes med det samme, uden at vente på weekenden.
Skal vi anmelde hændelsen, hvis vi finder tegn på udnyttelse?
Finder I tegn på, at nogen har udnyttet sårbarheden til at få adgang til systemer eller data, bør I vurdere anmeldelse til Datatilsynet, hvis persondata er involveret, og eventuelt politianmeldelse. Kontakt gerne en sikkerhedsrådgiver for at få kortlagt omfanget først.
Hvad gør vi, hvis vi ikke selv kan opdatere med det samme?
Aktivér TOKEN-autentifikation som midlertidig løsning, og begræns netværksadgang til API’et. Det lukker ikke sårbarheden helt, men fjerner muligheden for, at eksterne, uautoriserede angribere kan udnytte den.
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)
txtai through 9.10.0, fixed in commit 11b32da, exposes an API /reindex endpoint whose function body parameter is resolved through txtai.util.Resolver, which performs __import__ and getattr on the caller-supplied dotted path with no allowlist. When the API is exposed with no TOKEN configured (authentication is opt-in, so all endpoints are unauthenticated) and the index is configured writable, a remote attacker can set function to an arbitrary callable such as subprocess.getoutput, achieving remote code execution as the server process during reindexing. Exploitation requires those deployment conditions (API exposed, no TOKEN, writable index); it is not the default configuration. The fix gates the endpoint behind a new reindex configuration flag.
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.