AI-gateway patchen: wie beheert het versienummer

Tussen mei en september 2026 leverde een enkele AI-gateway drie vermeldingen op in de Known Exploited Vulnerabilities-lijst van CISA: CVE-2026-42208 op 8 mei, CVE-2026-42271 op 8 juni en CVE-2026-59822 op 2 september. De Nederlandse advisory voor de eerste verscheen op 11 mei, met prioriteit Normaal, op precies de dag dat de Amerikaanse federale deadline ervoor verliep. Draait er in uw landschap een AI-gateway, dan is de vraag wie het versienummer beheert.

Dit is geschreven voor degene aan wie straks wordt gevraagd welke versie er draaide: de IT-manager, informatiemanager, IT-directeur of security officer bij een Nederlandse organisatie van 250 tot 5.000 medewerkers. Wij zijn een gespecialiseerde AI-leverancier en niet uw ICT-partner. Wij beheren geen infrastructuur, netwerken of servicedesks, en niets hieronder vraagt u om patchbeheer naar ons te verplaatsen.

Wat gebeurde er met LiteLLM tussen april en september 2026?

LiteLLM is een open source proxy tussen applicaties en modelleveranciers: één API, veel modellen, met sleutels, budgetten en logging ertussen. Het is de component die een platformteam in week twee van een AI-project installeert, en degene waarvan wij zelf hosten hebben aangeraden wanneer een router het juiste antwoord is. Steeds vaker spreekt die ook MCP, het Model Context Protocol, waarmee de gateway behalve modellen ook tools doorgeeft.

Drie kwetsbaarheden erin kwamen in vier maanden op de uitbuitingslijst van CISA.

CVE-2026-42208 was een SQL-injectie in de controle van proxysleutels, CVSS 4.0 van 9.3, waarbij een door de aanvrager aangeleverde sleutel in de querytekst terechtkwam in plaats van als parameter mee te gaan. De fix kwam op 19 april 2026 in 1.83.7-stable. Sysdig registreerde de eerste uitbuitingspoging op 26 april om 16:17 UTC, wat in de verslaggeving binnen 36 uur na openbaarmaking werd geplaatst. Het rekenwerk in datzelfde artikel, afgezet tegen het indexeringsmoment van de GitHub-advisory, komt eerder op 26 uur uit. Die twee cijfers meten vanaf een ander startpunt, en in beide gevallen was het binnen twee dagen. CISA zette de CVE op 8 mei op de lijst, met 11 mei als federale deadline.

CVE-2026-42271, CVSS 8.7, was command injection via twee MCP-testendpoints die een volledige serverconfiguratie accepteerden en het meegeleverde commando op de proxyhost startten. Dezelfde fixversie, 1.83.7. Horizon3.ai combineerde die met CVE-2026-48710, de Starlette host-header-bypass die bekendstaat als BadHost, tot ongeauthenticeerde remote code execution en gaf de keten een 10.0. Op 8 juni op de KEV-lijst.

CVE-2026-59822 is de kwetsbaarheid met het label. Een authenticatiefout in het MCP streamable-HTTP-endpoint betekende dat elk willekeurig bearer token een werkende MCP-sessie opleverde: CVSS 4.0 van 8.8 bij de CNA, 8.2 onder CVSS 3.1 bij NVD, CWE-287 en CWE-306, alles vóór 1.84.0 geraakt. Het CVE-record verscheen op 8 juli 2026. Wiz zag uitbuiting in de eigen honeypot op 7 juli, een dag eerder. CISA voegde de CVE op 2 september toe met 16 september als uiterste datum, en meerdere analyses noemen dit de eerste MCP-kwetsbaarheid op de KEV-lijst.

De scan van Wiz in februari 2026 over 3.074 publiek toegankelijke instanties vond 294, oftewel 9,6 procent, die de gedocumenteerde standaard master key accepteerden, waarvan 191, oftewel 6,2 procent, helemaal geen authenticatie vroegen. Vanaf daar loopt de gepubliceerde keten via een pass-through route naar de metadataservice van de cloud en eruit met IAM-rolcredentials.

Waarom kwam de Nederlandse advisory na de uitbuiting?

Het NCSC publiceerde wel. NCSC-2026-0137, "Kwetsbaarheden verholpen in LiteLLM door BerriAI", versie 1.0.0, ging op 11 mei 2026 om 08:38 uit. De advisory dekt CVE-2026-42208 en CVE-2026-42271, noemt 1.74.2 tot en met 1.83.6 als geraakt en 1.83.7 als verholpen, en heeft prioriteit Normaal.

België was sneller. Het Centrum voor Cybersecurity België waarschuwde op 29 april 2026, drie dagen na de eerste waargenomen poging en twaalf dagen voor de Nederlandse tegenhanger, over dezelfde CVE en dezelfde fixversie.

Zet de data naast elkaar. De fix bestond op 19 april. Uitbuiting werd vastgelegd op 26 april. De Belgische waarschuwing kwam op 29 april. De Amerikaanse federale deadline viel op 11 mei. De Nederlandse advisory verscheen op 11 mei. Een organisatie waarvan het kwetsbaarhedenproces op de NCSC-feed leunt, en dat is het grootste deel van het Nederlandse middenbedrijf, kreeg een correcte en goed geschreven advisory vijftien dagen na de eerste waargenomen aanval, met een prioriteit die in geen enkele wijzigingsrij voordringt.

Tel de blootstellingsvensters, met twee aannames expliciet: dat een team patcht op het signaal waarop het daadwerkelijk is geabonneerd, en dat het daarna een wijzigingscyclus van twee weken nodig heeft tenzij het de release zelf als trigger neemt. Een team dat de releases van het project volgt en daarop beweegt dicht CVE-2026-42208 op 19 april, vóór de eerste geregistreerde poging op 26 april, zonder blootstelling. Geef dat team dezelfde cyclus van twee weken en het landt nog altijd rond 3 mei, een week blootstelling in plaats van een maand. Een team dat op de NCSC-feed vaart begint op 11 mei en zet de wijziging rond 25 mei door, 29 dagen na die poging. Een team dat wacht tot de CISA-lijst in een commerciële feed opduikt begint op 8 mei en landt rond 22 mei, 26 dagen erna. Dat verschil is geen kwestie van zorgvuldigheid. Het is een kwestie van op welke feed de component was geregistreerd.

Dat is geen kritiek op het NCSC, dat adviseert over wat het bereikt met een ernst die het eigen model onderbouwt. Het is een observatie over afhankelijkheid. Voor componenten die uw ICT-partner al tien jaar patcht is de feed één van meerdere overlappende kanalen, naast leveranciersbulletins en uw eigen scanner. Voor een Python-pakket dat een projectteam vier maanden geleden installeerde is de feed vaak het enige kanaal waarop iemand zich heeft geabonneerd.

Had uw prioriteringsmodel dit opgepikt?

Voor de MCP-fout waarschijnlijk niet, en dat is het deel dat u moet meenemen naar uw volgende evaluatie van kwetsbaarhedenbeheer. De SQL-injectie is een ander geval: bij CVSS 9.3 had elke risicogesorteerde rij die opgepakt. De authenticatiefout is degene die erdoorheen glipt, en die heeft de AI-specifieke vorm.

Op 13 oktober 2026 stond de EPSS-score voor CVE-2026-59822 in de metadata van Vulnerability-Lookup op 0,00836, op het 56,6e percentiel. EPSS schat de kans dat een kwetsbaarheid de komende dertig dagen wordt uitgebuit. Onder één procent, midden in de verdeling, is precies de vorm van een bevinding die een risicogesorteerde rij uitstelt. De eigen beoordeling van CISA voor dezelfde CVE, gedateerd 2 september, vermeldt uitbuiting "actief" en automatiseerbaar "ja".

Dat KEV, EPSS en CVSS het oneens zijn is geen nieuws. Vakgenoten hebben de algemene casus goed beschreven, en de eerlijke samenvatting is dat KEV bewijs over één kwetsbaarheid is terwijl EPSS een voorspelling over een populatie doet. Wat wij nergens beschreven zien is wat die onenigheid met een AI-component doet, en drie dingen maken het hier scherper dan bij een webserver.

De populatie is klein en jong, dus het signaal waarvan EPSS leert is dun. Een gateway die door een handvol interne diensten wordt bereikt genereert weinig van de scanruis die het model voedt.

Sommige fixes komen uit zonder CVE. De authenticatie-fallback in de MCP Python SDK werd verholpen in 1.30.0 en 2.2.0 onder een GitHub-advisory zonder CVE-nummer, één van drie MCP-authenticatiefouten in dertig dagen. Een scanner die op CVE-nummers werkt ziet die niet.

Uitbuiting kan het nummer voor zijn. Bij CVE-2026-59822 was dat zo, met één dag.

Wie beheert het versienummer van een AI-gateway?

In een landschap van 250 tot 5.000 medewerkers is het antwoord meestal "dat hangt ervan af aan wie u het vraagt", en dat is hetzelfde als niemand. Drie partijen zijn aannemelijke eigenaren en elk heeft een reden om te denken dat zij het niet zijn.

De eigen IT-afdeling of het platformteam heeft de gateway meestal geïnstalleerd, vaak in een container die een applicatieteam uitrolt. Staat de gateway in de Helm chart van dat team en niet in uw CMDB, dan ziet uw scanner een container image, geen product met een versie en een leverancier.

De ICT-partner patcht wat in het contract staat. Een beheerovereenkomst die vóór uw AI-programma is gesloten somt besturingssystemen, hypervisors, databases en endpoints op. Een gateway die in maand drie werd toegevoegd valt standaard buiten scope, en uw partner heeft gelijk als die dat zegt.

De AI-leverancier bouwde de applicatie erbovenop. Tenzij het contract iets anders zegt, eindigt die opdracht daar. Wij zeggen dat als die leverancier: wij beheren uw landschap niet, en wij doen niet alsof een gateway die voor een project is neergezet zichzelf patcht.

Geen van de drie heeft ongelijk over de eigen scope. Het gat is structureel: de component kwam via een project binnen, en projecten erven geen patchkalender.

De oplossing is een document, geen project. Leg voor elke AI-component vier velden vast: product en versie, de partij die de wijziging aanvraagt, de partij die goedkeurt, en het maximale interval tussen een gepubliceerde fix en het doorvoeren ervan. Zet het daar waar uw RFC-proces het ziet. Heeft u al vastgelegd wie gebeld wordt als een AI-systeem uitvalt, dan is dit dezelfde lijst in vredestijd, en dat is precies waarom het de moeite is om die één keer voor beide te schrijven.

Wat vraagt de Cyberbeveiligingswet hier van u?

Niets over LiteLLM in het bijzonder, en dat is het punt.

De Cyberbeveiligingswet trad op 15 augustus 2026 in werking en stelt eisen aan ruim 8.000 Nederlandse organisaties die essentiële of belangrijke diensten leveren. De zorgplicht vraagt een risicoanalyse en op basis daarvan passende en evenredige maatregelen voor de beveiliging van netwerk- en informatiesystemen. De meldplicht vraagt een melding van een incident bij het CSIRT en de toezichthouder zo snel mogelijk en in ieder geval binnen 24 uur. Het bestuur keurt de maatregelen goed en ziet toe op de uitvoering.

Nergens in die tekst staat een AI-gateway, en er staat evenmin een vrijstelling voor. Vraagt een auditor hoe technische kwetsbaarheden worden beheerst, dan is het antwoord dat overeind blijft een inventaris met eigenaren en intervallen, toegepast op alles wat bereikbaar is, en een gateway die model- en toolaanroepen doorgeeft is bereikbaar. ISO 27001:2022 legt dezelfde verplichting in beheersmaatregel 8.8, beheer van technische kwetsbaarheden, en een assetlijst die u nooit naar AI hebt uitgebreid hoort niet bij de maatregelen die van 27001 naar 42001 overdragen.

De klok van 24 uur is de praktische reden om eigenaarschap vooraf te regelen. Een melding binnen 24 uur wordt geschreven door wie weet welke versie er draaide. Moet die persoon eerst gezocht worden, dan is de klok al half verstreken.

Wat dit betekent voor een Nederlands IT-team in het middenbedrijf

Vijf dingen, in de volgorde waarin ze zich terugbetalen.

Breng in kaart welke AI-componenten er echt draaien: gateways en proxy's, MCP-servers, vectordatabases, orkestratiediensten, agent runtimes. Niet de modellen, maar het leidingwerk. Een wandeling door de deploymentmanifesten van uw AI-projecten vindt ze sneller dan welke scan ook.

Geef elke component een benoemde wijzigingseigenaar en een maximaal patchinterval. Twee weken voor alles wat vanaf internet bereikbaar is valt te verdedigen, en u krijgt uit twee richtingen tegenwerpingen. Kies een getal dat u haalt.

Abonneer u per component op de releasefeed van de bron, niet alleen op de nationale advisoryfeed. Voor een open source gateway is dat de pagina met releases en security advisories van het project. Dit is de enige stap die in april op tijd was.

Controleer vandaag eenmalig op standaardsleutels. Bijna één op de tien blootgestelde instanties in de scan van Wiz antwoordde op de sleutel die in de documentatie staat.

Zet de componentlijst in uw leveranciersgesprekken: de scopebrief van de ICT-partner en de opdrachtbeschrijving van de AI-leverancier. Daar sluit het gat definitief, in plaats van bij de volgende advisory opnieuw te worden ontdekt.

Wat hiervoor nodig is, is een lijst die een AI-component benoemt zoals uw landschap al een database benoemt, en een partij die voor de versie instaat. Die naad regelen wij terwijl een systeem wordt gebouwd, bij AI-implementatie in Nederland en bij toegepaste AI voor middelgrote organisaties.

Laatst bijgewerkt: 20 oktober 2026.

Veelgestelde vragen