CISA: Langflow-sårbarhet er aktivt utnyttet

CISA har lagt en ny Langflow-sårbarhet i sin Known Exploited Vulnerabilities-katalog. Det høres teknisk ut. Det er det også. Men den praktiske konsekvensen er enkel: verktøyene virksomheter bruker til å bygge AI-agenter og automatiserte arbeidsflyter må behandles som kritisk infrastruktur, ikke som sandkasseverktøy i utviklermiljøet.

Den amerikanske cybersikkerhetsmyndigheten publiserte varselet 21. mai og skriver at CVE-2025-34291 er lagt til KEV-katalogen basert på bevis for aktiv utnyttelse. CISA beskriver feilen som en origin validation error i Langflow. Kombinasjonen av for romslig CORS-konfigurasjon og en refresh-token-cookie satt med SameSite=None kan gjøre at en ondsinnet nettside sender cross-origin-forespørsler med brukerens legitimasjon. I verste fall kan en angriper få tak i tokens, nå autentiserte endepunkter, kjøre kode og få full systemkompromittering.

Langflow er ikke et tilfeldig bibliotek i bunnen av en applikasjon. Prosjektet beskriver seg selv som et verktøy for å bygge og deploye AI-drevne agenter og arbeidsflyter. Det betyr at sårbarheten treffer en kategori som mange virksomheter nettopp nå tester aggressivt: agentplattformer, interne copiloter, workflow-byggere og lavkodeverktøy som kobles mot data, API-er, filer og forretningsprosesser. Når slike verktøy eksponeres, blir de ikke bare en applikasjonsfeil. De blir et mulig inngangspunkt til hele agentmiljøet.

CISA setter frist til 4. juni 2026 for amerikanske føderale sivile etater. BOD 22-01 gjelder formelt disse etatene, men CISA skriver samtidig at alle organisasjoner bør prioritere retting av KEV-sårbarheter som del av sårbarhetsstyringen. Det er den delen norske virksomheter bør merke seg. KEV-listen er ikke en akademisk CVE-liste. Den er en katalog over sårbarheter der det finnes bevis for utnyttelse i praksis.

NVD-beskrivelsen gjør risikobildet mer konkret. Den peker på Langflow-versjoner til og med 1.6.9 og beskriver en kjedet sårbarhet som kan gi kontoovertakelse og fjernkjøring av kode. NVD har også en CVSS 4.0-score på 9,4 fra VulnCheck og en CVSS 3.1-score på 8,8 fra NVD. Github-utgivelsen for Langflow 1.9.3 fra 15. mai omtales som en kritisk sikkerhetsutgivelse og anbefaler umiddelbar oppgradering. Den nevner blant annet SSRF-beskyttelse, CVE-rettinger og oppdaterte sikkerhetsavhengigheter.

Poenget for ledere er ikke at alle bruker Langflow. Poenget er at agentverktøy ofte innføres uten samme disiplin som etablerte forretningssystemer. De havner i utviklermiljøer, data science-team, innovasjonslabber og produktavdelinger. De kobles til modell-API-er, interne dokumenter, databaser, CRM-systemer, ticketing, GitHub, Slack og skyressurser. Da blir spørsmålet ikke bare om verktøyet virker. Spørsmålet er hvem som eier det, hvem som patcher det, hvilke nøkler det har, og hva en kompromittering faktisk kan gjøre.

Dette er også et varsel om hvor raskt AI-stackens risikoprofil endrer seg. Mange virksomheter har god oversikt over ERP, e-post, identitet, endpoint og klassiske servere. Færre har samme oversikt over prototyper for agenter, MCP-servere, workflowbyggere og open source-verktøy som ble satt opp fordi noen skulle teste en idé. Men det er nettopp disse komponentene som får mer tilgang. En agent som bare leser demo-data er ufarlig. En agent som har tokens til interne systemer, kodebaser, kundedata eller produksjonsmiljø er noe helt annet.

For CIO og CISO bør denne saken utløse fire korte spørsmål. Først: har vi Langflow eller lignende agentbyggere i miljøet vårt, også i test og lokale containere? Deretter: er disse verktøyene i sårbarhetsskanningen, SBOM-oversikten og patch-SLA-en? Tredje spørsmål er tilgang: hvilke tokens, secrets og systemrettigheter ligger i agentplattformen? Fjerde spørsmål er logging: kan vi se om tokens er brukt uvanlig, om workflows er endret, og om agentverktøy har gjort kall det ikke pleier å gjøre?

Det er fristende å behandle dette som en enkel patchnyhet. Det er for smalt. Den større styringsbeskjeden er at AI-agentmiljøer må inn i den samme driftsmodellen som andre produksjonssystemer. Det betyr inventar, versjonskontroll, eier, tilgangsstyring, hardening, nettverksgrenser, secrets management, logging, backup, rollback og avvikshåndtering. Hvis verktøyet kan kjøre kode, hente tokens eller orkestrere handlinger på tvers av systemer, er det ikke lenger et leketøy.

Styret trenger ikke CVE-numrene. Styret trenger å vite om virksomheten har kontroll på nye teknologiflater som får reell operasjonell makt før de får reell styring. Langflow-saken er en konkret påminnelse. AI-agenter er ikke bare en produktivitetskategori. De er en ny angrepsflate.

Den praktiske anbefalingen er brutal og enkel. Finn interne Langflow-installasjoner og tilsvarende agentbyggere. Patch eller isoler dem. Roter tokens hvis det finnes tegn til eksponering. Fjern brede servicekontoer. Sett eksplisitte grenser for hvilke systemer agentverktøy kan nå. Og gjør KEV-sårbarheter til en lederrapportert patchkategori, ikke en backlog-linje som forsvinner mellom sprintene.

Kilder og medier

Primærkilde: CISA, "CISA Adds Two Known Exploited Vulnerabilities to Catalog", publisert 21. mai 2026: https://www.cisa.gov/news-events/alerts/2026/05/21/cisa-adds-two-known-exploited-vulnerabilities-catalog

CISA KEV-katalog: CVE-2025-34291 Langflow Origin Validation Error Vulnerability, lagt til 21. mai 2026, frist 4. juni 2026.

NVD: CVE-2025-34291, Langflow-versjoner til og med 1.6.9, CVSS-data og teknisk beskrivelse: https://nvd.nist.gov/vuln/detail/CVE-2025-34291

Langflow GitHub: prosjektbeskrivelse og sikkerhetsutgivelsen v1.9.3 fra 15. mai 2026: https://github.com/langflow-ai/langflow/releases/tag/v1.9.3

Thumbnail: OpenAI Image 2 / hogby.ai.