CVE-2024-34064

What it actually does

Affected Jinja versions allow the xmlattr filter to render attacker-controlled attribute names containing characters that are invalid in HTML/XML attribute keys, including '/', '>', and '='. When an application passes user-controlled dictionary keys into xmlattr, those characters can break out of the intended attribute name and create additional attributes or markup. This can lead to reflected or stored cross-site scripting when the rendered output is viewed by another user. User-controlled attribute values are not the core issue; the unsafe pattern is accepting untrusted attribute keys and rendering them as HTML attributes.

Why it matters to the business

Applications that use Jinja to render web pages may allow attackers to run script in another user's browser if they expose user-controlled attribute names. Consequences can include session theft, account actions performed as the victim, credential or token exposure, page defacement, phishing inside trusted application pages, and loss of user trust. The issue is moderate severity, is not known to be in CISA KEV, has low EPSS, and has no reported exploit maturity in the provided data, but it has been public for a long time and should still be remediated because the vulnerable pattern can exist deep inside application templates or helper code.

How an attack unfolds

An attacker first identifies an application feature that stores or reflects user-supplied keys into a structure later rendered by Jinja's xmlattr filter, such as configurable HTML attributes, profile metadata, custom fields, UI labels, theming options, widget attributes, or integration-provided dictionaries. Instead of supplying only benign attribute names, the attacker submits a crafted key containing an attribute-breaking character such as '=' or '>' and an event-handler attribute such as onmouseover, onclick, or onerror. When the application renders the template, xmlattr emits the malicious key into the tag without adequately rejecting all invalid attribute-name characters in affected versions. The browser interprets the output as one or more attacker-created attributes or markup rather than as a single safe attribute name. If another user views the affected page and the injected event triggers, attacker-controlled JavaScript runs in that user's browser in the origin of the vulnerable application.

How to fix it

Upgrade Jinja to version 3.1.4 or later. For source-based deployments, ensure the fix includes pallets/jinja commit dd4a8b5466d8790540c181590b14db4d4d889d57 or a later equivalent. In addition to upgrading, audit application code because accepting user-controlled keys into xmlattr is explicitly unsafe regardless of Jinja version. Only allow trusted, developer-defined attribute names; if dynamic keys are unavoidable, enforce a strict allowlist such as known-safe names or a conservative regular expression for HTML attribute names and reject any key containing whitespace, '/', '>', '=', quotes, control characters, or event-handler names such as onclick/onerror/onload. Continue to HTML-escape attribute values as normal, but do not rely on value escaping to protect unsafe attribute names. Consider replacing xmlattr for untrusted structures with explicit template logic that maps approved business fields to fixed attribute names.

How to confirm the fix worked

Confirm the runtime dependency version reports Jinja 3.1.4 or later using package manifests, lockfiles, SBOMs, virtual environment inventories, container image scans, and runtime introspection such as python -c "import jinja2; print(jinja2.__version__)". Search application templates and code for use of the xmlattr filter and determine whether any dictionary keys can originate from request parameters, persisted user content, integration data, imported files, or other untrusted sources. Add a regression test that attempts to render xmlattr with keys containing '/', '>', '=', spaces, and event-handler-style names and verifies they are rejected or never sourced from user input. Perform dynamic testing against features suspected of controlling rendered attribute names and verify crafted keys are not reflected as executable attributes in browser DOM inspection. Validate that dependency updates are present in built artifacts, deployed containers, serverless bundles, and any vendored copies of Jinja.

Typical attack path

1. Find a Jinja-rendered page or endpoint where user-controllable data influences keys in a dictionary passed to the xmlattr filter.
2. Submit a crafted attribute key containing invalid attribute-name characters such as '=', '>', or '/' to create a new HTML attribute or markup context.
3. Include an executable browser behavior such as an event-handler attribute or script-loading primitive in the injected attribute sequence.
4. Cause the vulnerable page to render the crafted data, either immediately for reflected XSS or later for stored XSS.
5. Wait for a victim user to view or interact with the rendered page so the injected JavaScript executes in the victim's browser session.
6. Use the executed script to read accessible page data, perform actions as the victim, redirect to phishing content, or exfiltrate tokens/cookies that are not otherwise protected.

How to detect it

There is no universal host-level indicator for this vulnerability because exploitation depends on the application passing untrusted keys into Jinja's xmlattr filter. To investigate prior exploitation, review HTTP access logs, application request logs, WAF logs, API gateway logs, and stored user-generated content for payloads that attempt to create HTML attributes or event handlers in fields that influence UI metadata, custom fields, profile attributes, widget settings, themes, or integrations. Focus on parameters or JSON object keys containing invalid HTML attribute-name characters such as '=', '>', '/', quotes, spaces, or encoded equivalents, especially combined with JavaScript event handlers or script URLs. Review rendered pages, database-backed content, cache entries, and audit trails for stored XSS payloads. Browser telemetry, CSP violation reports, and frontend error logs may show unexpected inline script execution, blocked script execution, or connections to unusual domains after viewing affected pages. If suspected, correlate the first appearance of the malicious content with account activity, session use, privilege changes, data exports, and requests made by victim users shortly after rendering the affected page.

• onerror=
• onload=
• onclick=
• onmouseover=
• onfocus=
• onmouseenter=
• javascript:
• <script
• ><script
• %3Cscript
• %3E%3Cscript
• alert(
• document.cookie
• localStorage
• sessionStorage
• new Image().src
• fetch(
• XMLHttpRequest
• /onerror=
• %2Fonerror%3D
• %3Donerror
• %3Eonerror
• xmlattr

What your security team should do

• Inventory all applications, services, containers, and build artifacts using Jinja and prioritize externally reachable or multi-user web applications.
• Upgrade Jinja to 3.1.4 or later, or to a downstream package version that includes the fixed commit dd4a8b5466d8790540c181590b14db4d4d889d57.
• Perform a targeted secure-code review for templates using the xmlattr filter, especially where dictionaries are built from request data, stored user settings, custom fields, metadata, or third-party integration payloads.
• Treat user-controlled attribute keys as a design flaw: replace them with server-side allowlists or mappings to fixed attribute names.
• Add static analysis or code review rules that flag xmlattr usage where keys are not clearly developer-controlled.
• Add tests for malicious attribute keys containing '=', '>', '/', whitespace, and event-handler names to prevent regression.
• Review web access logs, application logs, and stored user-generated content for suspicious attribute-injection payloads, especially in features that render configurable HTML or UI metadata.
• Ensure browser-side defenses such as HttpOnly/SameSite cookies and a restrictive Content Security Policy are in place to reduce XSS impact, but do not treat them as substitutes for fixing the vulnerable rendering pattern.