CVE-2019-10906 Jinja2 Sandbox Escape in Azure Linux and Microsoft Artifacts

In April 2019 the Pallets Jinja templating engine patched a high-severity sandbox-escape bug (CVE-2019-10906) by releasing Jinja 2.10.1; Microsoft’s public advisory for that CVE lists Azure Linux as an affected Microsoft product, but that listing does not mean Azure Linux is the only Microsoft artifact that can or does ship Jinja or that other Microsoft-maintained images, SDKs or services could not include a vulnerable Jinja build. The evidence shows Jinja is widely distributed across Linux distributions and within several Microsoft Python-based artifacts and container images, which means organizations running Microsoft-provided Linux images, SDK containers, or tools should evaluate them for vulnerable Jinja versions and apply updates or mitigations where necessary.

Background / Overview​

Jinja (also published as the Python package jinja2) is a ubiquitous Python template engine used by web frameworks (Flask), automation/tooling (Ansible, custom templating tools), SDKs, and container images. In versions prior to 2.10.1 a lesser-used string formatting path — str.format_map — could be used to escape Jinja’s sandbox. The vulnerability allows templates that are intended to be executed in a restricted sandbox to access objects and code outside that sandbox, producing sandbox escape conditions that can lead to data exposure or remote code execution depending on the surrounding application or environment. The upstream Pallets security post and CVE write-ups document the issue and the 2.10.1 fix.
The vulnerability was scored as high severity (CVSS 3.x 8.6 in published trackers), and Linux distributions, container image vendors and cloud providers subsequently published advisories and package updates. Debian, Red Hat and other distribution trackers list Jinja fixes in their errata; cloud images derived from those distributions — including Microsoft’s Azure Linux images — therefore needed updates to the system package python-jinja2 or the application-level jinja2 wheels included in images and containers.

---

What Microsoft publicly said about CVE-2019-10906​

Microsoft’s Security Response Center (MSRC) vulnerability page for CVE-2019-10906 states that Azure Linux was the Microsoft product identified as including the open-source Jinja library for that CVE, and that Microsoft will update the CVE entry if impact to additional products is discovered. That statement commits Microsoft to transparency for product impact and signals that at the time of the advisory their internal discovery process — or the public evidence they had — had mapped the vulnerable Jinja to Azure Linux images. (msrc.microsoft.com)
That wording is important: MSRC lists the Microsoft products it has identified as distributing a vulnerable component. It does not assert that no other Microsoft artifact includes Jinja. Instead, it reflects the scope of Microsoft’s internal product-impact analysis at that time and reserves the right to expand the product list if more inclusions are discovered later. In practice this means Azure Linux was the only Microsoft product Microsoft had flagged publicly for that CVE when the advisory was written — but it does not guarantee exclusivity. (msrc.microsoft.com)

---

Evidence that other Microsoft artifacts include Jinja​

While MSRC lists Azure Linux for CVE-2019-10906, independent evidence shows Microsoft-maintained Python images and repositories have included Jinja in the dependency lists of products, SDKs and sample container images. Two concrete examples illustrate this:

• Microsoft’s MLOps / Azure Machine Learning example image and related container requirements file lists Jinja2==2.10.1 (the patched version) among its Python dependencies for the image used in Azure ML scenarios. That listing shows Microsoft-produced or Microsoft-curated container images used in Azure ML workflows can and do include Jinja. Customers pulling Microsoft sample images or base images into their environments will therefore receive whatever Jinja version is present in those images. (learn.microsoft.com)
• Microsoft’s Azure Linux images are explicitly tracked by third-party security scanners and Nessus plugins which expect python-jinja2 as a package in Azure Linux and have bundled checks for multiple Jinja-related CVEs across different Jinja revisions. This confirms that Azure Linux images distribute the system python-jinja2 package and that the Azure Linux update pipeline has been the vector for Jinja security fixes in the Azure IaaS image ecosystem.

Put simply: Microsoft’s own sample and runtime images, SDK containers and tooling built from or packaged with community distributions frequently include widely used Python packages such as Jinja. Whether those artifacts are “Microsoft products” for the purposes of MSRC’s product-impact list depends on Microsoft’s internal product inventory and the time of the advisory; but the practical reality for customers is clear — multiple Microsoft-supplied images and artifacts can and do contain Jinja. (learn.microsoft.com)

---

Technical implications: when a Jinja CVE becomes a product CVE​

To judge impact you need to ask three technical questions for every Microsoft-provided image, runtime, SDK or service you consume:

• Does the Microsoft artifact ship a copy of the Jinja library (system package or Python wheel)? If yes, which version is installed?
• Is Jinja used in an execution context that renders untrusted templates (sandboxed templates) or otherwise exposes template rendering to attacker-controlled input?
• Are there mitigations in place — e.g., the Jinja sandbox in use with explicit safe-attribute overrides, or application-level input validation — that would neutralize the specific escape vector (format_map) even if a vulnerable Jinja were present?

If the artifact includes a vulnerable Jinja version and the rendering context accepts untrusted templates (or allows untrusted control of both template content and filename), the environment may be exploitable. The exact impact ranges from information disclosure to full remote code execution in the worst-case scenarios where template evaluation can reach sensitive interpreter objects. The original Jinja advisory and distribution errata enumerate these exploitation conditions and the safe remediation: upgrade to Jinja 2.10.1 or later, or explicitly disallow the format_map attribute in sandboxed environments.

---

Does “only Azure Linux” mean only Azure customer VMs are vulnerable?​

No. Practical exposure is broader than a single product listing.

• Azure Linux is the Azure-hosted, Microsoft-managed Linux image family for which Microsoft explicitly acknowledged Jinja distribution for this CVE. If you run Azure Linux VMs, you should ensure the system package python-jinja2 is updated to a fixed release in the image or applied via your configuration management tools. Nessus and other scanners have explicitly tied Jinja CVE checks to Azure Linux images.
• Other Microsoft-supplied images (for example Azure ML sample runtime images, curated Docker/OCI images hosted by Microsoft, or developer-centric sample images) may include Jinja as a Python dependency. That inclusion means those images could have been built with a vulnerable Jinja version at a given time. The fact that some Microsoft container images list Jinja (patched or not) as a dependency demonstrates the potential for exposure beyond a single product line. (learn.microsoft.com)
• Services that simply run user-supplied Python applications (App Service, Functions with user-deployed Flask/Django apps, containers deployed to Azure Container Instances) are only vulnerable when the user’s code includes a vulnerable Jinja package or executes templates in an unsafe way. Microsoft’s platform hosting does not automatically make every hosted app vulnerable; the vulnerability often lives in the application/container image rather than in the PaaS service control plane. This is an important distinction for operators.

---

Critical analysis: strengths and gaps in Microsoft’s approach​

Strengths

• Microsoft’s MSRC advisory and its commit to update CVE product lists when more impact is identified is a positive transparency move. Publicly asserting that Azure Linux distributed the vulnerable package gives customers an explicit point to start their investigations. That approach aligns with responsible disclosure and follows industry expectations: list identified impacted products and promise updates as investigations continue. (msrc.microsoft.com)
• The Azure Linux update pipeline historically follows distribution-provided errata and security updates, meaning Microsoft can rapidly push fixed python-jinja2 packages into its image catalog once the upstream patch lands. Distribution and image management reduce friction for tenants who stay current with Azure Marketplace image updates or who use Microsoft-managed images. Third-party scanner evidence shows those updates get tracked and applied across the Azure Linux family.

Gaps and risks

• Public product lists that name only one Microsoft product risk creating false confidence. Customers may assume that because only Azure Linux is mentioned no other Microsoft artifact includes the vulnerable library. However, Microsoft produces and curates many container images, SDK examples, sample projects and Python-based tooling — and those artifacts have included Jinja in the past. Public product-impact listings therefore must be read as the scope identified so far, not as an exhaustive inventory of every place Microsoft ever ships or stores third-party packages. The MSRC text does say as much, but it’s easy to overlook. (msrc.microsoft.com)
• Microsoft does not (and cannot reasonably be expected to) proactively patch every customer-provided artifact that runs on its cloud. Where vulnerable libraries are present inside customer containers, images, or app packages (for example a Flask app’s wheel inside a Dockerfile), remediation requires action by the image or application owner. This shared-responsibility model is correct but makes clear the difference between platform-fixed images (where Microsoft can act) and user-supplied artifacts (where the customer must act).
• Visibility and discoverability remain practical problems. Even when Microsoft publishes CSAF/VEX notices and CVE product lists (Microsoft announced a CSAF/VEX publishing program in October 2025), the onus remains on customers and security teams to scan image inventories, container registries, CI/CD pipelines and VM images for vulnerable packages embedded in artifacts. Automated SBOM and software composition analysis integration is the right long-term answer, but adoption and integration into operational workflows is uneven. (msrc.microsoft.com)

---

Actionable recommendations for customers and operators​

If you run workloads on Azure or use Microsoft-supplied images, follow this practical checklist to determine and mitigate exposure to Jinja CVEs such as CVE-2019-10906:

• Inventory images and Python artifacts:
• Build or extract SBOMs (software bills of materials) for every Microsoft-supplied image and every customer image deployed to Azure. Look specifically for jinja2 and python-jinja2 package versions in image manifests and layer metadata.
• Scan VMs, containers and build artifacts:
• Use vulnerability scanners (your VM/host scanner, container registry scanning, GitHub/CI Dependabot or third-party SCA) to detect Jinja versions older than 2.10.1 and any later Jinja CVEs.
• Patch Microsoft-managed images:
• If you use Azure Linux images managed by Microsoft, ensure you pull updated Marketplace images that include the patched distribution packages or apply the vendor-supplied package updates through your configuration management tooling. Nessus and distribution trackers show Azure Linux patches have been rolled out for Jinja-related CVEs.
• Patch or rebuild custom images:
• For container images and custom runtimes, update jinja2 in your requirements.txt, rebuild images, and redeploy. Where updating is not feasible immediately, implement application mitigations: avoid rendering untrusted templates and disallow format_map usage by overriding the sandbox is_safe_attribute method if you control the sandbox instance — this matches the Pallets guidance.
• Harden template usage:
• Where possible, avoid executing untrusted templates. If you must render untrusted templates, use strict sandboxing patterns, minimize available globals, and explicitly deny risky attributes and methods (notably format_map on strings for the CVE in question).
• Monitor vendor advisories:
• Track Microsoft’s MSRC product-impact pages and CSAF/VEX feeds; Microsoft has committed to publishing VEX/CSAF statements and updating CVE product lists when more affected products are found. Treat the MSRC CVE product list as the current finding, not the final answer—follow-up on vendor feed updates. (msrc.microsoft.com)

---

Practical examples and scenario mapping​

• Scenario A: You run an Azure VM from the Azure Linux image family. Action: Update system packages (apt update && apt upgrade or the distro-equivalent) or replace the VM with a marketplace image that includes the patched python-jinja2. Evidence from distribution trackers and Azure Linux scanner plugins confirms python-jinja2 is shipped and patched via image updates.
• Scenario B: You deploy a Docker container built from a Microsoft sample image that lists Jinja2 in its requirements.txt. Action: Rebuild the image with Jinja2>=2.10.1 (or latest secure version), re-scan the image and redeploy. Microsoft sample images (Azure ML examples) have historically listed Jinja in their requirements, so review sample repo manifests if you consumed them as bases. (learn.microsoft.com)
• Scenario C: You run server-side template rendering in an Azure App Service-hosted Flask app using a pinned older Jinja2 wheel. Action: Update the app’s dependencies, redeploy, and ensure templates cannot be controlled by untrusted inputs in a way that gives attacker control over template filenames or content. App Service itself does not automatically patch application dependencies in customer code.

---

How vendors — Microsoft and others — can improve clarity and customer outcomes​

• Publish SBOMs for all curated/managed images: Customers need machine-readable BOMs for marketplace and sample images so automated pipelines can detect vulnerable components without heavy manual forensics. Microsoft’s commitment to CSAF/VEX is a positive step; full SBOM publication would be a natural extension. (msrc.microsoft.com)
• Distinguish between platform and customer artifacts: Vendor advisories should clearly label whether an affected component exists in platform-managed code (the vendor can patch) or in customer-supplied application images (the customer must patch). This reduces triage time and prevents misinterpretation of impact scope.
• Integrate VEX/CSAF with image registries and update feeds: When a vulnerability is discovered, automated registry-level flags and rebuild triggers for marketplace images and curated containers would reduce exposure windows.
• Provide migration scripts and mitigations for legacy customers: For customers who cannot immediately update, provide documented mitigation steps — for Jinja this includes sandbox configuration guidance (deny format_map) and explicit code patterns to avoid.

---

Final assessment and bottom line​

• Microsoft’s MSRC advisory for CVE-2019-10906 named Azure Linux as the Microsoft product identified to contain the vulnerable Jinja library; that is accurate for the product-impact analysis Microsoft had at the time. However, naming a single product in a public advisory does not imply exclusivity. Other Microsoft-maintained images, SDK containers and example artifacts have been shown to include Jinja in their dependency lists; these artifacts are therefore candidate places where a vulnerable Jinja build could have been present and should be audited. (msrc.microsoft.com)
• For defenders: treat every Microsoft-supplied image, SDK container and sample project in your environment as a potential source of vulnerable third-party libraries. Inventory, scan and update. For operators of Azure Linux: follow Microsoft’s published image updates and ensure your VMs are running patched package releases. For customers who bundle Python dependencies into containers or apps, updating jinja2 and rebuilding images is the practical, direct fix.
• For Microsoft: preserve and accelerate the transparency trajectory. Publicly identifying affected products is necessary but not sufficient; machine-readable SBOMs and tighter integration between MSRC advisories, Marketplace image metadata, and CSAF/VEX feeds would turn a good transparency promise into practical, automated security outcomes for customers. (msrc.microsoft.com)

In short: Azure Linux was the only Microsoft product publicly named in the MSRC advisory for CVE-2019-10906, but it was not — and could not reasonably be assumed to be — the only place Microsoft-related artifacts might carry the Jinja library. Customers must therefore assume that any Microsoft-curated image, sample, or Python-based tool they run could include Jinja, and validate, patch, or mitigate accordingly. (msrc.microsoft.com)
Conclusion
CVE-2019-10906 demonstrates a recurring truth in modern software: widely reused open-source libraries create shared risk across ecosystems. Vendor CVE pages and product impact lists are essential starting points, but they do not replace comprehensive SBOM-driven inventories and active scanning of deployed artifacts. For Jinja vulnerabilities specifically, update to patched Jinja releases where present, harden any sandbox usage, and treat Microsoft-provided images the same way you would any other third-party image — verify and patch.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center