GitLab fixes CVE-2026-90970 critical at AI Gateway; patches for self-hosted

GitLab has published a safety notice that describes critical vulnerability in its AI Gateway service that, under certain conditions, allowed an authenticated user with access to the Duo Agent platform to escape from the "sandbox" of prompt templates and execute arbitrary commands in the gateway itself. The judgement has been recorded as CVE-2026-90970, received a CVSS score of 9.9 / 10 and GitLab published the correction on October 2. The versions containing the solution are 19.2.4, 19.3.2 and 19.4.1 of the AI Gateway component.

Confirmed facts: GitLab describes the problem as a weakness in the prompt template of a "custom flow" - custom flows created in the Duo Agent Platform to automate tasks - that could allow the "escape" of the safe environment and result in the execution of commands in the machine that runs the gateway. GitLab operates gateways administered for customers at GitLab.com and GitLab Dedicated and claims to have already mitigated the problem in its managed gateways; therefore, only organizations hosting their own AI Gateway (self-hosted) should apply the patch. The notice identifies the fixed versions above and does not list any alternative mitigation or an incorporated form to check if a gateway was attacked before updating it.

Technical context and scope: The AI Gateway is the component that connects a GitLab instance with external IA models and, in self-hosted deployments, is installed as a Docker image or by Helm. This gateway stores signature keys for JSON Web Tokens (JWT) and maintains connections with the internal GitLab and model providers - therefore the potential involvement is not only to the gateway container, but also to credentials that facilitate authentication and authorization in the environment. GitLab qualifies the problem as of the same kind as a previous vulnerability in February (CVE-2026-1868) - both related to weaknesses in the template engine, class CWE-1336 -, which indicates a pattern in how flow templates can be manipulated to break execution limits.

What we know and what not: confirmed is that an authenticated user with access to Duo Agent Platform was the attack route described; however, the notice does not detail the exact requirements (for example, what specific user role was necessary or what conditions of the gateway configuration were exploited). Nor has a public concept test been published, and the entry of the CVE includes an assessment of the CISA that lists the exploitation as "none" in its known field of exploitation, suggesting that there is no public confirmation of attacks in the general picture. Even so, the nature of vulnerability - execution of commands in a component that keeps sensitive keys - makes risk serious and with potentially serious consequences if exploited in productive environments.

Real consequences and risk for organizations: if an attacker manages to run code in a committed gateway, he can try to exfilter or rotate JWT keys, intercept or modify IA requests and responses, move laterally to the GitLab instance or model suppliers, and even deploy malicious loads. In environments where customer policy requires IA input and output data to remain within the perimeter (self-hosted gateway), the gateway exposure would compromise that guarantee and risk sensitive data. As it is a component that often has extensive network permits to communicate with GitLab and external APIs, the impact escalation is plausible.

Specific and immediate recommendations (verifiable and enforceable): 1) Update immediately any AI Gateway self-hosted to one of the corrected versions: 19.2.4, 19.3.2 or 19.4.1 as appropriate to the line using your installation. To deploy Docker, stop and remove the current container, make Docker pull from the new label and run the container with the same configuration; GitLab uses name labels such as self-hosted-v19.4.1-e. To deploy with Helm, adjust the image in the chart (image.tag) and apply help upgrade to display the new label. 2) Rotate sensitive keys and credentials: if the gateway saves JWT keys or model supplier credentials, prepare an immediate rotation plan for those keys after updating. Although there is no confirmation of operation, rotation mitigates the risk of prior commitment. (3) Review and restrict access: audit who has permits at Duo Agent Platform and apply the principle of minor privilege; consider disabling the creation of flows by non-essential users until the update is completed. 4) Monitoring and identifying indicators: review gateway and host logs to detect abnormal executions, unknown processes, sudden reinitiations or changes in flow settings; if you have snapshots or backup, compare them to detect modifications. 5) Test environment: first apply the patch in staging and valide environments to your GitLab version before you deploy in production, because the installation guide recommends using the gateway image corresponding to the lower GitLab version and the notice does not clarify inverse compatibility between versions.

Mitigation actions when it is not possible to update immediately: if operational restrictions cannot apply the patch immediately, reduce the risk - temporarily - by isolating the gateway network to limit its ability to communicate outside the perimeter, apply firewall controls to restrict incoming and outgoing access, and disable the flow functionality or user ability to load flow configurations until the update is possible. These measures are palliative and do not replace the software update.

What to communicate to the teams and next steps: inform the security and infrastructure teams, document the version of the gateway and the date / time of the update, keep login before rotating keys and notify compliance departments if the gateway manages regulated data. GitLab thanked the reporting researcher (user "invisiblemeerkat" in HackerOne) and already solved the problem in the gateways it manages for customers; however, the update responsibility lies with the self-hosted gateway operators.

Sources and additional reading: GitLab's safety notice and safety documentation of its services are available on GitLab's website ( https: / / about.gitlab.com / security /). The CVE entry is available in the NVD for structured details and associated links ( https: / / nvd.nist.gov / vuln / detail / CVE-2026-90970), and for technical context on the type of weakness referred to, see the definition CWE-1336 in MITRE ( https: / / cwe.mitre.org / data / definitions / 1336.html).

Summary: if you host your own AI Gateway, update now. If your GitLab is hosted by GitLab (GitLab.com, GitLab Dedicated or uses a managed gateway), GitLab indicates that your gateways were already patched and no action is needed on your part. Where it is not possible to update immediately, isolate, restrict access and prepare key rotations; document all actions and maintain enhanced monitoring until containment and verification is completed.