Ferske CVE-er treffer kjernen i AI-stacken

NISTs sårbarhetsdatabase NVD publiserte torsdag en ny høy-risiko CVE i vLLM. Den er liten i kode, men stor i konsekvens: en bruker kan eksplisitt slå av trust_remote_code, men to modellimplementasjoner setter likevel trust_remote_code=True internt. NVD beskriver resultatet som mulig fjernkjøring av kode via ondsinnede Hugging Face-modellrepoer.

Det er ikke en isolert pakke-feil. Samme døgn ligger det også ferske varsler på bordet for Langflow og LangChain/LangSmith. IBM beskriver en kritisk path traversal-feil i Langflow OSS som kan gi filtilgang og mulig fjernkjøring i fil- og RAG-komponenter. GitHub Advisory Database har samtidig høy-risiko-varsler for deserialisering i LangChain og LangSmith SDK.

Dette er akkurat typen risiko som er lett å undervurdere når AI-plattformer bygges raskt. Mange virksomheter behandler modellservere, agentrammeverk og RAG-verktøy som utviklerverktøy. I praksis står de ofte mellom eksterne modellrepoer, interne data, API-nøkler, vektorbaser og produksjonsmiljøer. Da blir en svak trust boundary ikke bare en teknisk bug. Den blir en inngang til data og drift.

Hva NVD varsler om i vLLM

CVE-2026-4944 gjelder vllm-project/vllm versjon 0.14.1. Ifølge NVD ligger problemet i vllm/model_executor/models/nemotron_vl.py og vllm/model_executor/models/kimi_k25.py, der parameteren trust_remote_code=True er hardkodet. Det kan overstyre brukerens eksplisitte --trust-remote-code=False.

NVD gir sårbarheten CVSS 8.8, høy alvorlighet. Den krever brukerinteraksjon i CVSS-vektoren, men det er ikke spesielt beroligende i moderne AI-drift. Mange pipelines henter, tester og deployer modeller fra registre som del av vanlig arbeidsflyt. Hvis miljøet laster NemotronVL- eller KimiK25-modeller fra et ondsinnet eller kompromittert repo, kan den lokale sikkerhetsantakelsen være feil.

Det viktigste poenget er ikke bare vLLM. Poenget er at flagg som skal begrense kjøring av ekstern kode må være reelle sperrer. Hvis de overstyres inne i modellspesifikk kode, hjelper det lite at plattformteamet har en policy på papiret.

Langflow viser RAG-risikoen

IBM varsler også om CVE-2026-7524 i Langflow OSS 1.0.0 til 1.9.1. Den får CVSS 9.8, kritisk. Feilen ligger i validering av symbolske lenker under utpakking av arkiver. IBM peker konkret på filprosessering i komponenter som Docling, Docling Serve, Read File, NVIDIA Retriever Extraction, Video File og Unstructured API.

Det er en ubehagelig kombinasjon. RAG-systemer er bygget for å ta imot dokumenter, tolke dem og gjøre innholdet søkbart. Hvis en angriper kan laste opp et arkiv med symlenker til sensitive filer, kan slike filer bli behandlet og lagret i vektorbasen. IBM beskriver scenarioer der hemmeligheter som JWT-nøkler kan hentes ut via chatbot-spørringer. Derfra kan risikoen flytte seg videre til token-forfalskning og kodekjøring.

IBM anbefaler oppgradering til Langflow OSS 1.9.2 og oppgir ingen workaround. For virksomheter som lar interne brukere eller kunder laste opp dokumenter til AI-flyter, bør det alene være nok til å starte en rask inventarjobb.

LangChain og LangSmith peker på samme mønster

GitHub Advisory Database beskriver CVE-2026-44843 i LangChain som en feil der eldre runtime-kode kan deserialisere run inputs, run outputs eller andre applikasjonsstyrte payloads med for brede allowlists. Berørte versjoner er langchain-core til og med 0.3.84 og 1.0.0 til 1.3.2. Patcher er 0.3.85 og 1.3.3.

CVE-2026-45134 gjelder LangSmith SDK. Prompt pull-metoder kan hente og deserialisere prompt manifests fra LangSmith Hub, der manifestet kan inneholde LangChain-objekter og modellkonfigurasjon. GitHub beskriver realistiske konsekvenser som SSRF, omdirigering av LLM-trafikk og påvirkning av runtime-konfigurasjon. Patcher er blant annet langsmith 0.8.0 for Python og 0.6.0 for npm.

Dette treffer et svakt punkt i agentstacken: mye av verdien ligger i gjenbrukbare prompts, verktøy, flows og modeller. Men gjenbrukbare artefakter kan også bli leverandørkjede. Når de kan påvirke runtime, nettverk eller modellklienter, må de behandles mer som kode enn som innhold.

Konsekvensen for CIO og CISO

AI-sikkerhet handler ikke lenger bare om prompt injection og datalekkasje i chatgrensesnittet. Den praktiske angrepsflaten ligger også i modellservere, notebook-nære pakker, agentrammeverk, filparsing, prompt stores og modellregistre. Mange av disse delene eies av produkt- og datateam, ikke av tradisjonell infrastruktur. Det gjør ansvarsbildet uklart.

Tre grep bør tas raskt. Først: finn ut hvor vLLM, Langflow, LangChain og LangSmith faktisk brukes. Ikke bare i produksjon. Se også på PoC-er, interne agentprosjekter og sandkasser med tilgang til data eller nøkler.

Deretter: stram inn modell- og artefaktkilder. Tillatelseslister for modellrepoer, pinning av versjoner, scanning av tredjepartsmodeller og krav om gjennomgang før nye modellfamilier tas inn bør være normale kontroller. Et trust_remote_code=False-flagg er ikke nok hvis ingen tester om hele stacken respekterer det.

Til slutt: behandle RAG-opplastinger og prompt manifests som aktivt innhold. Filparsing bør kjøres isolert, med minst mulige rettigheter, uten tilgang til produksjonshemmeligheter. Prompt og agent-konfigurasjon som hentes utenfra bør ha samme vurdering som tredjepartsbiblioteker.

Dette er ikke grunn til å stoppe agentprosjekter. Det er grunn til å profesjonalisere driften. AI-stacken har flyttet seg fra lab til produksjon. Da må patching, SBOM, secrets-hygiene, runtime-isolasjon og leverandørstyring følge etter.

Kilder og medier

Primærkilde: NIST NVD, CVE-2026-4944: https://nvd.nist.gov/vuln/detail/CVE-2026-4944

Supplerende kilder: IBM Security Bulletin om CVE-2026-7524 i Langflow OSS: https://www.ibm.com/support/pages/node/7273426

Supplerende kilder: GitHub Advisory Database om CVE-2026-44843 i LangChain: https://github.com/advisories/GHSA-pjwx-r37v-7724

Supplerende kilder: GitHub Advisory Database om CVE-2026-45134 i LangSmith SDK: https://github.com/advisories/GHSA-3644-q5cj-c5c7

Thumbnail: OpenAI Image 2 / hogby.ai