AI Gateway Patching: Who Owns the Version Number

Between May and September 2026, one AI gateway produced three entries on CISA's Known Exploited Vulnerabilities catalogue: CVE-2026-42208 on 8 May, CVE-2026-42271 on 8 June, and CVE-2026-59822 on 2 September. The Dutch advisory for the first landed on 11 May, at priority Normaal, the same day the United States federal deadline for it expired. If an AI gateway runs in your estate, the question is who holds its version number.

This is written for whoever will be asked which version was running: the IT manager, informatiemanager, IT director or security officer at a Dutch organisation of 250 to 5,000 people. We are a specialist AI supplier, not your ICT partner. We do not run infrastructure, networks or service desks, and nothing below asks you to move patch management to us.

What happened to LiteLLM between April and September 2026?

LiteLLM is an open-source proxy between applications and model providers: one API, many models, with keys, budgets and logging in the middle. It is the component a platform team installs in week two of an AI project, and the one we have recommended self-hosting ourselves when a router is the right answer. Increasingly it also speaks MCP, the Model Context Protocol, making the gateway a tool broker as well as a model router.

Three of its vulnerabilities reached CISA's exploited list in four months.

CVE-2026-42208 was a SQL injection in the proxy's API-key check, CVSS 4.0 of 9.3, where a caller-supplied key landed in the query text instead of being passed as a parameter. It was fixed in 1.83.7-stable on 19 April 2026. Sysdig recorded the first exploitation attempt on 26 April at 16:17 UTC, which the reporting put inside 36 hours of the bug becoming public. The same article's own arithmetic against the GitHub advisory index time puts the gap nearer 26 hours. The two figures measure from different starting points, and either way it was under two days. CISA added the CVE on 8 May with a federal deadline of 11 May.

CVE-2026-42271, CVSS 8.7, was command injection through two MCP test endpoints that accepted a full server configuration and spawned the supplied command on the proxy host. Same fixed version, 1.83.7. Horizon3.ai chained it with CVE-2026-48710, the Starlette host-header validation bypass known as BadHost, into unauthenticated remote code execution and rated the chain 10.0. KEV on 8 June.

CVE-2026-59822 is the one carrying the label. An improper-authentication flaw in the MCP streamable-HTTP endpoint meant any bearer token produced a working MCP session: CVSS 4.0 of 8.8 from the CNA, 8.2 under CVSS 3.1 at NVD, CWE-287 and CWE-306, everything before 1.84.0 affected. The CVE record was published on 8 July 2026. Wiz observed exploitation in its honeypot on 7 July, one day earlier. CISA added it on 2 September with a due date of 16 September, and several write-ups call it the first MCP vulnerability on the KEV list.

Wiz's February 2026 scan of 3,074 publicly exposed instances found 294, or 9.6 percent, accepting the documented default master key, of which 191, or 6.2 percent, required no authentication at all. From there the published chain runs through a pass-through route to the cloud metadata service and out with IAM role credentials.

Why did the Dutch advisory arrive after the exploitation?

NCSC-NL did publish. NCSC-2026-0137, "Kwetsbaarheden verholpen in LiteLLM door BerriAI", version 1.0.0, went out on 11 May 2026 at 08:38. It covers CVE-2026-42208 and CVE-2026-42271, names 1.74.2 through 1.83.6 as affected and 1.83.7 as fixed, and carries priority Normaal.

Belgium was faster. The Centre for Cybersecurity Belgium warned on 29 April 2026, three days after the first observed attempt and twelve days before its Dutch counterpart, on the same CVE and the same fixed version.

Read the dates next to each other. The fix existed on 19 April. Exploitation was recorded on 26 April. The Belgian warning came on 29 April. The United States federal deadline fell on 11 May. The Dutch advisory published on 11 May. An organisation whose vulnerability process is driven by the NCSC feed, which describes most of the Dutch mid-market, received a correct and well-written advisory fifteen days after the first observed attack, at a priority that does not jump a change queue.

Count the exposure windows, with two assumptions stated: that a team patches on the signal it actually subscribes to, and that it then needs a two-week change cycle unless it treats the upstream release itself as the trigger. A team watching the project's own releases and moving on one closes CVE-2026-42208 on 19 April, before the first recorded attempt on 26 April, for no exposure at all. Give that team the same two-week cycle and it still lands around 3 May, a week of exposure rather than a month. A team following the NCSC feed starts on 11 May and lands the change around 25 May, 29 days after that attempt. A team waiting for CISA's catalogue to surface in a commercial feed starts on 8 May and lands around 22 May, 26 days after. The spread there is not diligence. It is which feed the component was registered against.

That is not a criticism of NCSC, which advises on what reaches it at a severity its own model supports. It is an observation about dependency. For the components your ICT partner has patched for a decade, the feed is one of several overlapping channels, alongside vendor bulletins and your scanner. For a Python package a project team installed four months ago, the feed is often the only channel anyone subscribed to.

Would your prioritisation model have flagged this?

For the MCP flaw, probably not, and that is the part to take to your next vulnerability-management review. The SQL injection is a different case: at CVSS 9.3 any risk-ranked queue would have raised it. The improper-authentication flaw is the one that slips through, and it is the one with the AI-specific shape.

On 13 October 2026 the EPSS score recorded for CVE-2026-59822 in Vulnerability-Lookup's metadata was 0.00836, at the 56.6th percentile. EPSS estimates the probability that a vulnerability will be exploited in the next thirty days. Under one percent, in the middle of the distribution, is exactly the shape of a finding that a risk-ranked queue defers. CISA's own assessment of the same CVE, dated 2 September, reads exploitation "active" and automatable "yes".

That KEV, EPSS and CVSS disagree is not news. Practitioners have written the general case well, and the fair summary is that KEV is evidence about one vulnerability while EPSS is a prediction about a population. What we have not seen written is what the disagreement does to an AI component specifically, and three things make it sharper here than for a web server.

The population is small and young, so the signal EPSS learns from is thin. A gateway reached by a handful of internal services generates little of the scanning noise that feeds the model.

Some fixes ship without a CVE. The MCP Python SDK's authentication fallback was fixed in 1.30.0 and 2.2.0 under a GitHub advisory with no CVE assigned, one of three MCP authentication bugs in thirty days. A scanner keyed to CVE identifiers does not see it.

Exploitation can precede the identifier. For CVE-2026-59822 it did, by a day.

Who owns the version number of an AI gateway?

In a 250 to 5,000 FTE estate the answer is usually "it depends who you ask", which is the same as nobody. Three parties are plausible owners and each has a reason to think it is not them.

Internal IT or the platform team usually installed it, often inside a container an application team deploys. If the gateway lives in that team's Helm chart rather than in your CMDB, your scanner sees a container image, not a product with a version and a vendor.

The ICT partner patches what the contract lists. A managed-services agreement signed before your AI programme enumerates operating systems, hypervisors, databases and endpoints. A gateway added in month three is out of scope by default, and your partner is right to say so.

The AI supplier built the application on top of it. Unless the contract says otherwise, that engagement ends there. We say that as that supplier: we do not run your estate, and we will not pretend a gateway deployed for a project patches itself.

None of the three is wrong about its own scope. The gap is structural: the component arrived through a project, and projects do not inherit a patch calendar.

The fix is a document, not a project. For each AI component record four fields: product and version, the party who raises the change, the party who approves it, and the maximum interval between a published fix and the change landing. Put it where your RFC process can see it. If you have already settled who gets paged when an AI system fails, this is the same list in peacetime, which is why it is worth writing once for both.

What does the Cyberbeveiligingswet require of you here?

Nothing about LiteLLM specifically, and that is the point.

The Cyberbeveiligingswet took effect on 15 August 2026 and sets requirements for more than 8,000 Dutch organisations providing essential or important services. Its zorgplicht asks for a risk analysis and, on that basis, passende en evenredige maatregelen for the security of network and information systems. Its meldplicht requires an incident report to the CSIRT and the supervisor as quickly as possible and within 24 hours at the latest. The board approves the measures and oversees their implementation.

Nothing in that text names an AI gateway, and nothing in it excuses one either. If an assessor asks how technical vulnerabilities are managed, the answer that survives is an inventory with owners and intervals applied to everything reachable, and a gateway brokering model and tool calls is reachable. ISO 27001:2022 puts the same obligation in control 8.8, management of technical vulnerabilities, and an asset list you never extended to AI is not one of the controls that transfer from 27001 to 42001.

The 24-hour clock is the practical reason to settle ownership in advance. A notification inside 24 hours is written by whoever knows which version was running. If that person has to be found first, the clock is already half spent.

What this means for a Dutch mid-market IT team

Five things, in the order they pay off.

List the AI components actually running: gateways and proxies, MCP servers, vector databases, orchestration services, agent runtimes. Not the models, the plumbing. A walk through your AI projects' deployment manifests finds them faster than any scan.

Give each one a named change owner and a maximum patch interval. Two weeks for anything internet-reachable is defensible, and you will be argued at from both sides. Pick a number you will meet.

Subscribe per component to the upstream release feed, not only to the national advisory feed. For an open-source gateway that is the project's releases and security advisories page. This is the only step that was in time in April.

Check for default credentials once, today. Nearly one in ten exposed instances in Wiz's scan answered to the key printed in the documentation.

Put the component list into your supplier conversations: the ICT partner's scope letter and the AI supplier's statement of work. That is where the gap closes permanently rather than being rediscovered at the next advisory.

What this needs is a list that names an AI component the way your estate already names a database, and a party who answers for its version. That seam is what we handle while a system is being built, in AI implementation in the Netherlands and in applied AI for mid-sized organisations.

Last updated: 20 October 2026.

Frequently asked questions