CVE-2026-9198: Langflow utfärdade superanvändartoken till vem som helst och körde sedan det de skickade

IBM:s bulletin för CVE-2026-9198 beskriver hur Langflow OSS kan övertas med två förfrågningar: ett anrop till plattformens endpoint för automatisk inloggning returnerar en bearer-token för superanvändare till vem som helst som begär den, och ett andra anrop skickar Python till endpointen för kodvalidering, som kör den. Leverantören registrerar kedjans två halvor under separata identifierare – CVE-2026-9103 för den saknade autentiseringen, CVE-2026-8481 för körningen – och bedömer kombinationen till 9,8 enligt CVSS 3.1, nåbar över nätverket utan behörigheter och utan användarinteraktion. Standarddistributioner på versionerna 1.0.0 till och med 1.10.0 är drabbade; åtgärden är 1.10.1, och IBM anger ingen tillfällig lösning. USA:s myndighet för cybersäkerhet och infrastruktursäkerhet (Cybersecurity and Infrastructure Security Agency) lade till CVE:n i sin katalog Known Exploited Vulnerabilities den 4 augusti 2026, med en federal åtgärdsfrist till den 7 augusti. Posten, dess allvarlighets- och skadetaggar samt de poster som registrerades kring den finns i Orca AI Incident Archive, som listar denna händelse tillsammans med resten av serien.

Kedjan, i tre IBM-bulletiner

IBM publicerar den här sårbarheten som tre dokument i stället för ett, och det är genom att läsa dem tillsammans som mekanismen blir tydlig. Hela kedjan är CVE-2026-9198, ett kodinjektionsproblem under CWE-94, poängsatt till 9,8 med vektorn AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — nåbar över nätverket, låg komplexitet, inga privilegier, ingen användarinteraktion och hög påverkan på konfidentialitet, integritet och tillgänglighet. Dess första halva, CVE-2026-9103, är bristande autentisering för en kritisk funktion under CWE-306, också 9,8. Dess andra halva, CVE-2026-8481, är CWE-94 igen men poängsatt till 9,9: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, låga privilegier i stället för inga, och ändrad omfattning.

9,9 är den ärliga delen av aritmetiken. Slutpunkten för kodvalidering var aldrig i sig öppen för utomstående – IBM beskriver den som en sårbarhet som lät "vilken autentiserad användare som helst köra godtyckliga systemkommandon med Langflow-serverprocessens fulla privilegier." Det som gör kedjan oautentiserad är den första halvan: autologin-slutpunkten, som enligt IBM:s redogörelse "utfärdar långlivade bearer-token för superanvändare utan att kräva autentisering när konfigurationen AUTO_LOGIN är aktiverad (aktiverad som standard)". Bulletinen tillägger att tokenarna har en 365-dagars livslängd och dokumenterar en andra exponeringsväg som får mindre uppmärksamhet – tillåtande standardinställningar för resurssdelning mellan olika ursprung som tillåter jokerteckenursprung med autentiseringsuppgifter, vilket IBM säger "skulle kunna möjliggöra drive-by-tokenstöld från godtyckliga webbplatser."

Exekveringsdelen är den del som är värd att fundera närmare på. IBM:s sammanfattning säger att validatorn ”kompilerade och exekverade användarskickad kod, inklusive utvärderingar som sker när funktionen definieras, såsom standardargument och dekoratorer”, och att en angripare därför kunde smuggla in ett exekverbart uttryck i en standardparameter eller en dekorator. Det är inte ett bildligt uttryck om osäker kod: en dekorator utvärderas när den omslutande def konstrueras, så en förfrågan vars enda angivna syfte är att kontrollera syntaxen för en funktion kör fortfarande allt som är kopplat till den. IBM:s egen kedjade säkerhetsrådgivning säger detsamma i en enda sats — validering och exekvering var samma operation. Rättelsen som dokumenterades i CVE-2026-8481-bulletinen var ”att ta bort kodkörning från valideringssökvägen och endast utföra kompileringskontroller”.

En liten avvikelse är värd att notera eftersom den påverkar hotjakten. Den kedjade bulletinen anger token-slutpunkten som /api/v1/auto_login, och det gör även Cloud Security Alliance och Field Effect; IBM:s separata CVE-2026-9103-bulletin anger den som /api/v1/login/auto_login. Båda IBM-dokumenten beskriver samma slutpunkt och ingen av dem har fel om beteendet. Exekveringssökvägen skrivs identiskt överallt: POST /api/v1/validate/code.

Varifrån datumen kommer

Arkivet daterar denna post till 6 augusti 2026. CISA:s katalogpost, läst den 30 oktober 2026, registrerar tillägget som 4 augusti 2026 och fastställer åtgärdsfristen till 7 augusti. Den omgivande rapporteringen ligger på vardera sidan om arkivets datum i stället för på det: Field Effect publicerade den 5 augusti, och cvetodo och Thailands nationella datorberedskapsorgan publicerade båda den 7 augusti. En registrering, fristen den ger upphov till och artiklarna som skrivits om den är tre olika händelser, så dessa datum motsäger inte varandra — men tvådagarsglappet mellan arkivets fält och CISA:s är anledningen till att läsa katalogen när det exakta datumet har betydelse.

Det är svårare att fastställa när informationen offentliggjordes, och källorna är genuint oeniga. IBM:s bulletinsida för den kedjade CVE:n anger ett initialt publiceringsdatum på 2 juli 2026 och ett ändringsdatum på 17 augusti 2026. Field Effect daterar IBM:s offentliggörande till 2 juli. Cloud Security Alliances forskningsnotis från 18 augusti anger att offentliggörandet, och lanseringen av 1.10.1 tillsammans med detta, skedde den 17 juli; cvetodo säger samma sak. Femton dagar skiljer de två tolkningarna åt och ingendera dokumentet är slarvigt, så den här artikeln väljer inte mellan dem. Vad som är fastställt oavsett är att patchen publicerades före KEV-listningen, och att 1.10.1 är den version som innehöll den.

Det som CISA:s post exakt säger, i sina egna fält, är snävare än dess rubrik. Produkten ligger under leverantören IBM med produkten Langflow; sårbarheten beskrivs som en "som gör det möjligt för oautentiserade angripare att uppnå fullständig fjärrkodkörning på standarddistributioner av Langflow"; känd användning i ransomwarekampanjer registreras som Okänd; forensisk triage är markerad som obligatorisk enligt BOD 26-04; och den åtgärd som krävs är att tillämpa motåtgärder i enlighet med leverantörens instruktioner, eller att upphöra med användningen av produkten där motåtgärder inte är tillgängliga.

Exploateringsprotokollet

CISA:s listning hävdar att sårbarheten användes i det vilda. De offentliga bevisen bakom detta påstående är tunnare än vad 9,8 antyder. Varken IBM eller CISA har namngett en hotaktör eller publicerat detaljer om en observerad kampanj – Field Effect säger detta rakt ut, och inget i de tre IBM-bulletinerna eller KEV-posten motsäger det.

Det som i stället finns är leverantörstelemetri som vidarebefordrats andrahand. Cloud Security Alliances not citerar KEVIntel för påståendet att exploateringsförsök registrerades med början "omkring 6 juli 2026", veckor före offentliggörandet enligt alliansens egen beräkning, och att de kumulativa försöken fram till mitten av augusti hade vuxit till hundratals, med ursprung i flera hundra unika internetadresser spridda över dussintals länder. Dessa siffror kommer från ett enda övervakningsföretag och förekommer inte i någon annan källa som granskats för den här artikeln. De rapporteras här, men är inte bekräftade.

Startdatumet är värt en andra titt. Om försöken verkligen började omkring 6 juli är det fyra dagar efter det bulletindatum som IBMs sida anger och elva dagar före det 17 juli-datum som två andra källor anger. Telemetrin varken bekräftar eller vederlägger därför något av de två offentliggörandedatumen; Cloud Security Alliance presenterar båda förklaringarna utan att välja och beskriver den tidiga aktiviteten antingen som oberoende upptäckt av opportunistiska skannrar eller som en läcka av tekniska detaljer före ett koordinerat offentliggörande.

Offentlig exploitkod är den bättre dokumenterade delen. Field Effect tillskriver kedjans offentliga beskrivning till "en offentlig proof-of-concept som publicerades i juli 2026" i repositoriet github.com/0xdak/CVE-2026-9198_exploit och säger att koden demonstrerar hur man erhåller en superanvändartoken via autologin-endpointen och sedan använder den mot validerings-endpointen. Field Effect kopplar inte repositoriets författare till någon observerad exploatering, och det gör inte den här artikeln heller. Inte heller rapporterar någon genomgången källa en bekräftad stöld av autentiseringsuppgifter från en exploaterad värd: beskrivningen av insamling av autentiseringsuppgifter som allmänt åtföljer Langflow-sårbarheter är en bedömning av vad en sådan värd innehåller, som behandlas nedan, inte ett fynd om något namngivet offer i denna post.

Etablerad, rapporterad och inte etablerad

• Fastställt. Att CVE-2026-9198 kedjar samman saknad autentisering i autoinloggningsändpunkten med kodkörning i kodvalideringsändpunkten; att IBM bedömer kedjan som 9.8 enligt CWE-94 och dess två halvor som 9.8 och 9.9; att standarddriftsättningar av Langflow OSS 1.0.0 till och med 1.10.0 är drabbade på Windows, macOS och Linux; att 1.10.1 är rättningen och att IBM inte publicerar någon tillfällig lösning; och att CISA lade till CVE:n i KEV-katalogen med en federal tidsfrist den 7 augusti 2026. De tre IBM-bulletiner är de primära dokumenten och de stämmer överens med varandra om mekanismen.

• Oberoende återgivet.ThaiCERT återgav samma kedja med två ändpunkter, samma poäng på 9,8, samma påverkade intervall och samma åtgärd i 1.10.1 i sin rådgivning av den 7 augusti 2026, och lade till en nätverkskontroll som IBM-bulletinerna inte innehåller: håll Langflows administrativa gränssnitt utanför det publika internet och nå det endast via VPN eller en strikt lista över tillåtna adresser. Det är en bekräftelse på hur rådgivningen lästes, av en myndighet som inte har något intresse i leverantörens formulering — inte en oberoende upptäckt av felet.

• Rapporterat, inte bekräftat.Varje exploateringssiffra: hundratals försök, flera hundra adresser, dussintals länder, med början omkring 6 juli. Detta är siffror från ett övervakningsföretag, vidarebefordrade av en forskningsorganisation. CISA:s förteckning bekräftar att exploatering förekom utan att kvantifiera den, och ingen annan telemetrikälla förekommer i materialet som granskats här.

• Inte fastställt. Inget namngivet offer och ingen namngiven aktör. Ingen attribuering till en stat eller en kriminell grupp. Ingen bekräftad siffra på hur många Langflow-instanser som var nåbara från internet — cvetodo rapporterade den 7 augusti att IBM inte hade besvarat frågor om omfattningen av exploateringen — och inget leverantörsuttalande sedan dess som kvantifierar det. Arkivet graderar denna post med förtroendegrad A och markerar den inte som omtvistad, och inget som granskats här bestrider det; luckorna är luckor i den offentliga bevisningen, inte i påståendet att sårbarheten finns och har använts.

• Avsiktligt uteslutet.ThaiCERT:s rådgivning beskriver också AI-styrd automatiserad skanning under samma vecka, men kopplar den till en annan produkt i samma CISA-batch, inte till Langflow. Det utgör inte bevis för denna post och används inte här som sådant.

Vad förändrades efter noteringen

Leverantörens åtgärd är en versionshöjning och inget annat. IBM:s tabell över berörda produkter listar Langflow OSS 1.0.0 till och med 1.10.0, anger 1.10.1 som rättelse och sätter "None" i fältet för workarounds – i alla tre bulletiner. Bulletinen för CVE-2026-8481 beskriver ändringen: validatorn slutade exekvera och började kompilera. Bulletinen för CVE-2026-9103, som täcker autoinloggningsdelen, redogör inte för sin rättelse i samma detalj, och inget IBM-dokument som granskats här anger datum för utgåvan 1.10.1.

Alla andras vägledning går längre än leverantörens. Cloud Security Alliance rekommenderar att uppgradera och sedan verifiera vid körning att autologin-slutpunkten inte längre utfärdar token till oautentiserade anropare, i stället för att lita på versionssträngen – det angivna skälet är att tidigare Langflow-patchar har levererats med ofullständiga korrigeringar. Den rekommenderar också att uttryckligen ställa in miljöinställningen LANGFLOW_AUTO_LOGIN på false, så att plattformen kräver riktiga autentiseringsuppgifter i stället för att skapa dem, och att behandla alla instanser som har varit internetexponerade sedan början av juli som komprometterade i avvaktan på en logggranskning, med rotering av autentiseringsuppgifter för allt som instansen kunde nå: modellleverantörsnycklar, databasautentiseringsuppgifter och molntjänstnycklar. ThaiCERT tillägger nätverksdelen – inget administrativt gränssnitt på det publika internetet, endast VPN eller tillåtelselista. Båda är forskarnas rekommendationer. IBM publicerar inga.

En kreditrad finns i protokollet. IBMs bekräftelse tillskriver rapporten Harish Kolla, GitHub-handtag Har1sh-k. Cloud Security Alliance placerar, i sin not från den 18 augusti, CVE-2026-9198 som den fjärde distinkta Langflow-sårbarheten av typen oautentiserad åtkomst eller auktoriseringsbypass som når CISA:s katalog på ungefär fem månader, och namnger de tre tidigare identifierarna; dess tolkning är att mönstret speglar upprepad lappvis åtgärdning av en och samma autentiserings- och kodexekveringsmodell snarare än orelaterade defekter. Den inramningen är alliansens bedömning, presenterad i en forskningsnot; den är inte ett fynd av en oberoende revisor, och ingen källa som granskats här registrerar något offentligt svar från underhållarna på den.

Vad KEV-listningen avgör och inte avgör

CISA:s katalog är ett påstående om observerat utnyttjande, inte en incidentrapport, och den här posten håller sig till den formen. Den säger att sårbarheten användes; den säger inte mot vem, av vem eller hur ofta. Användning av ransomware anges som Okänt. Inget kvantifieras. Det som listningen faktiskt avgör är den enda fråga ett allvarlighetsbetyg inte kan besvara: huruvida sårbarheten gick från ett fungerande proof of concept till verklig användning. För organisationer utanför räckvidden för BOD 26-04 – vilket är större delen av världen – innebär tidsfristen den 7 augusti ingen skyldighet, och det faktum som ligger bakom den har samma tyngd som det skulle ha haft med en sådan skyldighet.

Cloud Security Alliance drar den operativa slutsatsen från samma post: att en KEV-listning är en tillförlitlig signal om att exploatering har passerat proof-of-concept-stadiet, och att den för den här sårbarheten kom ungefär en månad efter de första registrerade försöken. Den som väntade på katalogen innan den började triagera var, enligt den tolkningen, redan i färd med att hantera en incident snarare än att förebygga en. Om det beskriver en viss driftsättning är en fråga för dess loggar — det endpoint-par som ska sökas efter är det som IBM dokumenterade, och posten namnger inte ett enda offer för att testa svaret mot.