Sign in Subscribe

Your Self-Hosted AI Gateway Needs Its Own Patch Routine

Your Self-Hosted AI Gateway Needs Its Own Patch Routine

On 2 October 2026, GitLab disclosed and patched CVE-2026-90970, a flaw in the GitLab AI Gateway. That is the service a self-managed GitLab instance can run to power its own private GitLab Duo AI features. GitLab rates it Critical with a CVSS score of 9.9, and NVD gives it the same score. In GitLab's words, it "could have allowed an authenticated user with Duo Agent Platform access to escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway."

The flaw was reported through HackerOne by invisiblemeerkat. GitLab fixed it in AI Gateway versions 19.2.4, 19.3.2 and 19.4.1 and published the details, and the gateways GitLab hosts were already fixed. For teams running their own gateway, though, applying that fix was their job alone. That is the part worth learning from.

Your self-hosted AI gateway is its own component

When you set up GitLab Duo with self-hosted models, you are not flipping a switch inside GitLab. You are deploying a second service. The AI Gateway sits between your GitLab instance and your model. GitLab sends it requests, the gateway builds the prompts from templates, and then it calls the model.

GitLab documents the gateway on its own install page (install_ai_gateway), separate from the main install and upgrade guides. That separation is the whole lesson. The gateway has its own container image, its own version number and its own upgrade step. Upgrading the main GitLab application does not upgrade the gateway.

So your GitLab instance can show a fully current version on its Help page while the gateway behind it is several releases old. The main version number tells you nothing about whether the gateway is patched.

First, check whose gateway you use

Whether this CVE is your problem depends on which gateway your instance talks to. GitLab says that "Customers using GitLab.com, GitLab Dedicated, and GitLab Self-Managed instances using a GitLab-hosted AI Gateway are protected and do not need to take action."

Look at the AI gateway URL your instance is configured to use. If it points to a host on your own network, you run the gateway and the patch is yours. If nobody on your team remembers setting it up, find out who did before you go any further.

Then ask the running gateway what version it is

Check the thing that is actually running, not your notes or your compose file. On a Docker host, list the running containers and their images:

docker ps --format '{{.Names}}  {{.Image}}'

On Kubernetes, find the gateway pod and read its image:

kubectl get pods -A | grep -i gateway
kubectl describe pod <pod-name> -n <namespace> | grep Image:

The image tag is the version you deployed. If you deployed with a moving tag instead of a version number, the tag does not tell you what is running. In that case, use this upgrade to switch to a pinned version tag, so that next time a single glance at the tag tells you where you stand.

A patch routine for the gateway that actually works

This is the routine I would set up for any self-hosted AI gateway, using this CVE as the example.

1. Know when a fix ships

GitLab publishes its patch releases as posts on its releases blog, which you can follow by RSS. It also offers security notification emails. Send one of them somewhere you actually read every day.

GitLab also says it "conducted targeted outreach to Self-Hosted AI Gateway customers prior to this release post". That is good practice, but outreach only reaches the contact GitLab has on file. If that contact is a former colleague's inbox, the warning goes nowhere. Keep the contact current, and do not make it your only signal.

2. Know your fixed version line

For CVE-2026-90970, the affected AI Gateway versions are:

  • all versions from 18.1.6 before 19.2.4
  • all of 19.3 before 19.3.2
  • all of 19.4 before 19.4.1

The fixed versions are 19.2.4, 19.3.2 and 19.4.1. If you are on 19.3.x, move to 19.3.2. If you are on 19.4.0, move to 19.4.1. If your gateway is still on an 18.x release, the advisory lists no fixed 18.x version, so you need to move to a fixed 19.x release. Before you do, check GitLab's AI Gateway documentation to see which gateway versions work with your GitLab version, because that jump may mean upgrading GitLab as well.

3. Patch the gateway as its own step

Give the gateway its own line in your upgrade runbook, right after the main GitLab upgrade. If it is not written down, it will get skipped on the night you are tired. With Docker Compose, pin the fixed tag in your compose file and then run:

docker compose pull
docker compose up -d

With Helm, change the image tag in your values file and run helm upgrade for the gateway release.

4. Verify the running version afterward

An upgrade log that ends without errors only tells you a command finished. It does not tell you the new container is the one serving traffic. Run the same docker ps or kubectl describe check again and confirm the tag is a fixed version.

Also check that no old gateway container is still running next to the new one, and try one Duo feature from GitLab to confirm the gateway still answers. Then write the version and the date in your notes.

Set the urgency honestly

As of 3 October 2026, there is no public report of this flaw being exploited in the wild and no public proof-of-concept, and it is not in CISA's Known Exploited Vulnerabilities catalogue. That is a reason to patch calmly in your next maintenance window, not a reason to wait. A 9.9 rating on a component that can be made to run commands is worth an evening.

Least privilege: who has Duo Agent Platform access

This flaw could not be triggered from outside. It needed an authenticated user with Duo Agent Platform access. That makes the list of people with that access a real security control, not paperwork.

Work through that list now, and again on a schedule:

  • Review it. List every user, bot and service account that has Duo Agent Platform access. Pay the most attention to who can create or change custom flows, because a crafted flow configuration was the way in here.
  • Limit it. Give access to the people who use it, not to every account by default. Remove it from accounts that have not used it.
  • Offboard it. When someone leaves, block their GitLab account the same day and revoke their personal access tokens. A forgotten account with AI access is exactly what a flaw that requires an "authenticated user" needs.

Then limit what the gateway itself can reach. Command execution on the gateway means access to whatever the gateway host can touch. Keep it on a private network that only your GitLab instance can reach. Give it only the credentials it needs to call your model, and keep unrelated secrets off that host. I covered these ideas in more detail in my earlier post on the controls a self-hosted AI agent needs, and they apply to the gateway just as much.

The honest trade-off of owning the box

Look at how this played out for the two groups. Customers on GitLab.com, GitLab Dedicated or a GitLab-hosted gateway were protected centrally and did not have to do anything. People running their own self-hosted AI gateway had to notice the release, find their version and upgrade it themselves.

That is the deal you take when you own the box. You keep your code and prompts on your own hardware, and you choose your own models. In return, you are the operations team, and nobody pushes a fix to your server for you.

It is still a good deal. When a fix ships, nothing stands between you and applying it. You can patch tonight on your own clock, see for yourself that the fixed version is running, and decide who gets access. You are not waiting in a vendor's rollout queue or watching a status page.

The deal only works if every component is on your list. Write down each piece of your AI stack: GitLab itself, the AI Gateway, whatever serves your model, and the reverse proxy in front. Each one has its own version and its own update path. This time the gateway was the one that mattered. Next time it could be any of the others.

If you would rather not do this yourself

Keeping a self-hosted stack current is not hard, but it never stops. If you would rather have someone keep your self-hosted stack patched and hardened for you, including the gateway pieces that are easy to forget, take a look at my services page.

Fiverr: hiteshsaini459 · Upwork: hiteshsaini25