The template sandbox had a second door

GitLab on Friday published a critical patch for the AI Gateway, the service that provides GitLab's Duo AI features. The flaw, CVE-2026-90970, is rated 9.9 out of 10. According to the advisory, an authenticated user with access to the Duo Agent Platform could "escape the prompt template sandbox via a specially crafted flow configuration, leading to arbitrary command execution on the AI Gateway." The fixed releases are 19.2.4, 19.3.2 and 19.4.1. GitLab has already fixed the gateways it runs itself, so customers on GitLab.com, GitLab Dedicated, or Self-Managed instances that use a GitLab-hosted gateway need do nothing. Customers that run their own gateway, through GitLab Duo Self-Hosted, need to upgrade.

The exposure lasted a long time. GitLab lists every gateway release from 18.1.6 onwards as affected, and in the gateway's public repository the tag for the self-hosted 18.1.6 build points to a commit dated 9 September 2025. The fix is public too. The tags for the three fixed releases point to commits dated 17 September 2026, 15 days before the advisory, and GitLab says it contacted self-hosted gateway customers directly before publishing. The commit is titled "block Jinja block-set NSRef writes on non-namespace objects". The advisory credits a researcher using the handle invisiblemeerkat.

Jinja is the Python templating library the gateway uses to assemble prompts, and the advisory's weakness class, CWE-1336, is improper handling of template syntax. Jinja's sandbox lets a template set an attribute with the syntax {% set ns.attr = value %} only when ns is a special namespace object, and before allowing the write it inserts a check that this is so. GitLab's code comment explains that the longer block form, {% set ns.attr %}...{% endset %}, "never emits that check, so it can write an arbitrary key/attribute onto any object exposed to the template". It adds: "No sandbox hook sees this either way." This desk read the compiler in Jinja 3.1.6, the current release on PyPI, published in March 2025. The plain form has the check. The block form does not. GitLab's patch adds the check in the gateway's own subclass of Jinja's code generator, not in Jinja itself.

The patch closes a second gap. It changes Jinja's default filter table so that reverse cannot be applied to a dictionary, citing "a CPython memory-safety bug (python/cpython#154709)" and calling the change "a critical security measure to prevent remote arbitrary code execution". That CPython issue, opened in July, shows that calling reversed() on a dictionary after it has been cleared and refilled can read past the end of its key table, which crashes ordinary builds of the interpreter. Python's developers merged a fix and backported it to the 3.13, 3.14 and 3.15 branches on 29 July. The new tests also reject several other filters when given the wrong type: last on a dictionary, and indent, wordwrap and safe on a list. GitLab has not explained how the pieces were combined into an exploit. The patch shows which ones it decided to close.

The general problem goes beyond GitLab. Prompt templates are code. A product that lets users define their own agent flows is letting them write templates, and the safety of that rests on the template engine's sandbox. Jinja's sandbox has needed repairs before: the project published three sandbox-breakout advisories between December 2024 and March 2025. Any team that builds prompts from user-supplied Jinja templates has a reason to check whether its sandbox allows the block-set form, since in the current Jinja release that form carries no such check.

The conditions narrow the risk but do not remove it. An attacker needs a GitLab account with Duo Agent Platform access, so the threat is a malicious insider or a stolen login, not an anonymous scan. The advisory does not mention exploitation, and the flaw was not in CISA's Known Exploited Vulnerabilities catalogue as of its release on Friday. GitLab has been on that list recently: CISA added CVE-2026-85706, a path traversal in GitLab Community and Enterprise Editions, on 11 September with a three-day deadline. Self-hosted gateway operators should move to one of the fixed releases and check gateway logs for flow configurations they do not recognise.